Mindset

Приветствую, Хаброзритель. В данной статье я хочу познакомить тебя с органайзером Notion, поделиться своим опытом использования. Также я дам несколько советов, идей, к которым я пришел со временем, учась планировать и использовать свое время, силы и мыслетоплево.

Некоторые мысли, конечно, не будут напрямую связаны с данной программой и не все советы я как-то выделил отдельно, не упусти их.

Надеюсь, что буду полезен и прошу под кат.

Что такое Notion?

Notion - это органайзер, который предлагает использование мощного функционала реляционных баз данных пользователю, не знакомому с данной технологией, в красивой обертке. Вы можете настраивать связи между различными таблицами, гибко фильтровать свои данные, создавать вложенность любой глубины. Также в Notion есть возможность отформатировать ваши данные в виде таблицы, календаря, доски agile, диаграммы Ганта и другими способами. Конечно имеется поддержка todo-list, нумерованных или маркированных списков, различных разделителей, блоков кода, есть вставка видео или аудио, даже существует поддержка LaTEX.

Огромное количество функционала и гибкости разработчики смогли спрятать за минималистичным и лаконичным интерфейсом. Лично я, от стадии "ааа странно, что? где?", перешел к стадии полного понимания того, что и как можно сделать буквально за 10-20 минут. Мне хотелось иметь пространство "для всего", и когда команда Notion открыла бесплатную версию, я нашел его.

Почему может быть сложно начать его использовать?

На написание данной статьи меня натолкнул пост "Почему не Notion". Выводы данного поста и некоторых комментариев можно описать так: "На организацию рабочего пространства уходит времени больше, чем на саму деятельность" или метафорично(укороченная цитата из того поста) "Перед тем как создать записку, вам надо создать стол, стул, листок и ручку".
Я с этим не согласен, и в моей голове сразу промелькнула одна интересная мысль:

Не нужно использовать сразу всё, что предоставляет данная программа. Пусть ваше пространство в Notion растет итеративно. Со временем оно само идеально подстроится под ваши нужды.

На просторах интернета можно найти различных личностей, например Томас Франк, с красивыми, качественными, продуманными дашбордами. Увидев такое, может даже стать немного завидно.
Некоторые из тех, кто "пропагандирует" Notion, могут делиться своими шаблонами (заранее настроенными страницами), но:

Я не рекомендую качать готовые шаблоны, если только они полностью вам не подходят. Они вряд-ли будут удобны, так как их создали не вы. Также, ИМХО, будет ощущение чего-то чужого. Notion должен стать продолжением вас самих, вашим вторым мозгом.

Мой путь Notion

В данном абзаце, я расскажу, какой путь прошел мой Notion и покажу небольшие уловки/мелочи, которые упрощают реализацию желания - "быть более продуктивным".

Первая таблица

Первой причиной, для чего я хотел попробовать Notion, было планирование. Мне не зашел ни один планировщик, который я когда либо пробовал. В одном удалялись старые задачи, в другом не было связей, третий был неудобен в плане UX, в другом не хватало полей. Я даже бросился писать свою версию, но на данный момент этот проект лежит в черном сером ящике.

Итак, первое, что я решил попробовать в Notion - создать таблицу с задачами и отталкиваться от этого.
Посмотрите, как это выглядело, и я немного поясню, в чем был кайф:

Первая таблицаДоступные типы полейВид календаряДиаграмма ГантаAgile таблица

Изначально, мною была создана таблица, которую видно на первом скриншоте. Для меня это был абсолютно первый опыт и я был приятно удивлен тому, как создатели данного приложения подошли к функции добавления какого либо блока(календарь, таблица, галерея или просто текст и тд.). Начав новый абзац, вы просто нажимаете \ и выбираете нужный блок в выпадающем списке с помощью стрелок.

В данной таблице, на выбор есть различные типы полей[второй скриншот]. Вы можете легко добавлять теги, сортировать по ним. Можете добавлять напоминания. По началу было обидно, что вы не можете сделать повторяющиеся напоминания, но через некоторое время использования я понял, что это большой плюс. Повторяющиеся напоминания захламляют ваш мозг и отпугивают от приложения.

Следующую приятную эмоцию я испытал тогда, когда узнал, что в выпадающем списке, в левом верхнем углу, можно одним нажатием добавить дополнительную визуализацию.
После первого клика, у меня появилась возможность, открыв Notion, увидеть план в форме календаря на завтра, сегодня или любой другой день[скриншот 3].

После второго, по диаграмме Ганта[скриншот 4], я смог видеть какие блоки времени заняты, какие свободны и использовать это. Ранее я планировал в основном "на листочке", часто использовал timeboxing (советую изучить эту идею, если слышите о ней впервые). Некоторые дни даже пробовал расписывать весь день от пробуждения до сна блоками по 25 минут. Получалось отлично, но я не готов так делать каждый день. Данная диаграмма[скриншот 4], позволяет применять данный подход в очень удобном виде и без особых усилий. Конечно, у вас есть возможность манипулировать блоками на данной диаграмме, что очень удобно.
Итак, третий клик, и мы имеем agile таблицу. Из за проф. деформации, такой подход, лично мне, очень удобен. Мозг перестает видеть что-то лишнее, он не отвлекается, вопрос "что делать?" встает редко, я сконцентрирован только на столбце InProgress. Столбцы это те-же теги, никто не мешает вам добавить или удалить что-либо.

Всё максимально гибко.

Каждая строка/ячейка/box это такая же страница. Вы можете "провалиться" в неё, добавить вложенности, текста, дополнительных полей. Почти всё, что может придумать ваша фантазия, можно реализовать. Я решил последовать первому совету, написанному выше, и не увлекаться.

Первый дашборд

Однажды мне посоветовали видео Стеллы Васильевой, о том, как она настроила свои пространства. Мне понравилась идея некого дашборда, централизованного места, главной страницы, и я решил сделать нечто похожее. Ранее, выбирать страницы из "дерева" слева, мне было попросту не удобно.

То, что у меня получилось, можно увидеть на следующем скриншоте:

Первый дашборд

Реализовав свою версию дашборда, я познакомился с тем, как можно приятно кастомизировать свое рабочее пространство. Я добавил изображение в header, научился добавлять иконки к страницам, узнал как разделить пространство на несколько столбцов.
На дашборде я решил разместить backlog/inbox справа, и небольшую agile таблицу, для отслеживания текущего дня.

Ранее я держал под рукой тетрадку, в которую можно было быстро записать то, что неожиданно вспомнил, дабы не засорять ОЗУ головы. Теперь этот список был в дашборде Notion.
В agile таблицу я вывел story-point, estimation time и некоторые дополнительные теги. Есть возможность перетянуть строку из таблицы сразу в agile-board. Все дополнительные поля (story-point, estimation time) сразу добавляются к странице, которая была перетянута.

Страница "Книги" на данном дашборде не представляет особого интереса, "Plan Legacy" был описан выше.

Также я добавил описание утренней рутины. Notion у меня всегда включен на отдельном рабочем столе MacOS, поэтому часто находился перед глазами. Как показывает практика, то что я вижу перед глазами, со временем "само" становится новой привычкой. Привычки же формируют ту личность, которой ты хочешь стать.

Советую попробовать наклеить стикеры, парой слов описывающие привычки, которые вы хотите получить. Стикер должен находиться перед глазами максимально большой процент дневного времени. Для меня это рабочий стол дома, зеркало в ванной, и самое главное - дверь холодильника, именно то место, за которое его открываешь. Недавно я добавил туда стикер "думать позитивно".
Эффект не заставил себя долго ждать.

Как я и говорил ранее, каждая ячейка, или строка таблицы - это такая же страница, с таким-же гибким функционалом.

Открыв любую задачу в agile-board, можно увидеть более подробное описание, прогресс, блоки кода:

Страница с описанием задачи

Всё было бы хорошо, если бы не одно но.
Backlog очень быстро разрастается, начинает пугать, его становится невозможно разобрать.

Текущий дашборд

Итак, у меня была проблема постоянно растущего inbox. Одной из основных причин данной проблемы был постоянный поток идей. Конечно такой поток в сотни раз быстрее, чем возможность их исполнения. Для меня это действительно проблема: хватаешься за несколько проектов, по итогу ни один не доходит до конца, даже, казалось бы несложный проект о написании статьи на habr.

Решение пришло из workflow scrum. Создавать пользовательские истории, жестко ограничить их количество, и двигаться по ним.

Получившийся дашборд выглядел таким образом:

Галерея историй

Как можно заметить из данного скриншота, я взял идею Стивена Кови из книги "7 навыков высокоэффективных людей" о том, что нужно развивать в себе 4 вида интеллекта: ментальный, физический, духовный, социальный. Когда существует гармония в развитии этих 4-х интеллектов, ты счастлив. Если развитие какого-либо интеллекта "проседает", ты можешь начать чувствовать упадок, что в свою очередь негативно влияет на развитие оставшихся.

Пользовательские истории, в данном контексте, должны придерживаться нескольким несложным правилам:

1. Название. Как тот, кто играет определенную роль, пользователь(я) делаю определенную вещь, для того, чтобы развить определенную черту, важную для данной роли.

2. Должен быть четкий критерий окончания, даже если его очень сложно придумать.

3. Дедлайн. Если его нет, то мозг может посчитать, что задачу можно не делать еще оочень долго. Никогда.

4. Должно быть четкое понимание того, зачем нужна эта история.

Пример описания, одной из историй можно увидеть ниже:

Описание истории

На доске, для истории о чтении книг, я попробовал поле с типом "формула". Функционал формул минималистичен, но достаточен. Процедуры и функции хорошо задокументированы и, как мне кажется, даже если у вас нет опыта программирования, при должном желании, вам не составит труда в них разобраться. К примеру я сделал формулу, которая выводит прогресс чтения книги:

concat(    "Прочитано ",    slice(format(prop("Страница остановки #") /         prop("Последняя страница #") * 100), 0, 5),     "% книги.")

Вид вывода формулы на странице

В данном коде prop - берет значение поля, format - кастует любой тип данных в строку, slice - обрезает, оставляя только первые 5 символов и concat - конкатенирует/склеивает.
Так это выглядит:

Доска после добавления формуы

Мне очень нравятся практики, которые Максим Дорофеев предлагает в своих книгах "Путь джедая" и "Джедайские техники". Одна из таких практик - писать первое действие, которое надо выполнить. Так проще обезьянке сиюминутного удовольствия. Во многих планировщиках это сделать можно только костылями.

В Notion можно добавить любое количество полей, и я начал это использовать в описаниях задач:

Пример использования правила "писать первое действие"

Когда я реализовал всё вышеописанное, я испугался. "Как следить за всеми этими историями?" Всё разложено по полочкам, но каждый раз лазать по полочкам не круто, не удобно, не эффективно. В тот раз я добавил графу "следующее действие" к истории. Хочу напомнить, что добавив поле на одну страницу, оно появляется на аналогичных. В данное поле я продублировал некоторые даты из задач внутри истории.

На следующее утро я был приятно удивлен. Уведомления на многие задачи стояли на 5 утра, и проснувшись я увидел небольшой инбокс на сегодня. Всё, что прилетело в этот инбокс, я легко перенес в agile-board для задач на сегодня, который заранее создал под галереей с историями.
Продуктивный день начался.

Также у меня наконец появилась страница с красиво оформленными блокнотам на различные темы.

Notion стал "всё в одном". Он стал тем, что я относительно давно искал.

Вид записной книжки

Выводы

По моему мнению, Notion очень удобный, гибкий, настраиваемый под любые "хотелки" инструмент, который может быть полезен каждому. Итеративно, он становится идеальным именно для вас. Облако очень быстро синхронизирует все ваши таблицы с телефоном. Также вы можете использовать его для командной работы, аналогично Jira/Confluence, но я данный функционал не пробовал.

Это однозначно тот инструмент, который я не мог не посоветовать, особенно учитывая то, что бесплатной версии может быть более чем достаточно.

Приятного опыта использования.

Всем привет! Хочу сразу сказать, что все выводы из этой статьи - квинтэссенция опыта моей инженерной (да и не только) деятельности. За свою трудовую деятельность я успел поработать и слесарем(по разным направлениям), и мастером на заводе, и инженером-проектировщиком в сфере ПГС, и системным-администратором, сейчас вот работаю программистом. Считаю, что многое из статьи применимо в принципе к любой трудовой деятельности и не только технической. Разница только в масштабах. По сути, хочу поделиться опытом, и возможно кто-то возьмет его на вооружение.

В любой работе должна быть система

Именно этому пункту я отвожу центральное место в работе инженера. Именно его больше всего игнорируют большинство тех инженеров, которых я знаю и это большая боль. Для начала хочу донести, что я подразумеваю под системой. Система - это самый крупный узел в проекте, который состоит из дерева более мелких узлов. Здесь важно понять суть - у каждого она может быть своя: у программиста - набор проектов и их взаимосвязи, у конструктора - сборка его 3D-моделей, у мастера на производстве - агрегаты и трубопроводы, находящиеся в его сфере обслуживания. Другими словами - архитектура.

Очень часто можно увидеть отсутствие системы в отсутствии системных решений и правил. Я очень часто наблюдал и наблюдаю точечные решения проблем без разработки системного решения. Как вариант, случай из моей практики. "На крупном заводе функционировала система теплоснабжения. Единая магистраль от которой запитывались все отопительные системы цехов (для тех, кто в теме - зависимая схема подключения). Потом заметили, что в одном из цехов прохладнее, чем нужно. Пошли слесаря, покрутили краны, вроде потеплело. Зато в другом месте на заводе стало холоднее. Разрегулировали. Поставили дроссельные шайбы - не помогло. Так слесаря и ходили из цеха в цех, краны крутили."

Другой пример из IT. Есть такое выражение, "Хороший сисадмин ленивый сисадмин. Только лень заставит его настроить все раз и навсегда". Всякий раз, когда возникает схожая проблематика, или похожая неисправность, значит вероятно проблема не решена системно. Из IT еще неплохой пример - костыли, быстренько пишешь и задача решается, но... Не системно - локально. Все мы знаем, что происходит дальше - код начинает хромать с нашими костылями. Система сбоит.

В машиностроении та же проблематика. Например у автомобиля, поставленного на серию, постоянно ломается какой-то узел или агрегат. Это также системная ошибка и решать ее нужно переработав конструктив автомобиля, а не чинить в автоцентре каждый экземпляр. Можно было бы рассмотреть и вариант, что это программируемая поломка, но это тема отдельной статьи. При этом архитектура проектов у инженеров-машиностроителей также оставляет желать лучшего - нет четкого разделения по логике, которое в основном заключается в нарушении уровней сборки. Дерево сборок получается неровным.

Разделяй и только тогда будешь властвовать

Любая, даже самая сложная система, состоит из менее крупных узлов. В любом случае должна. Ракету не строят монолитным куском. Вместо этого в ней присутствуют блоки. Как и, к примеру, в автомобиле. Он состоит из следующих систем: кузов, трансмиссия, двигатель, электрика и т.п. То есть вышеперечисленные системы даже проектировать могут и, в большинстве случаев, должны разные люди. В итоге получается своего рода конструктор, который потом нужно просто собрать.

Система может быть очень сложной, но тут нужно определить ее составляющие узлы. Система - является большим узлом, который состоит из других, более мелких, узлов. Эти, более мелкие узлы могут быть также составными узлами или примитивными (неразборными) объектами. То есть большую систему можно и нужно декомпозировать на более мелкие. Если и более мелкие узлы могут быть декомпозированы, то их также стоит раздробить. То есть нужно проектировать иерархию системы. И чем больше эти узлы будут изолированы друг от друга, тем лучше. Например, как вариант решения вышеописанной проблемы в теплоснабжении цеха, можно было бы поставить по теплообменнику в каждый цех и регулировать пришлось бы только систему теплоснабжения самого цеха, при этом другие участки теплосети не пострадали бы.

В IT - то же самое. На языке разработки ПО это называется "Сильная связность, слабое зацепление." Похоже на GRASP, не так ли? Пилишь немаленький проект и все запихиваешь физически в один файл-проект IDE-шки. Поначалу многие так делают. Зато потом тестировать подобное решение - так себе удовольствие. Разбиваешь на пакеты, где в одном - бизнес-логика, в другом - представление, в третьем - оставшийся кусок используемого паттерна MV*. И уже совершенно другая картина. Согласны? На моей практике, коллеги по цеху долго не могут выполнить подобную декомпозицию. Банально разбить на подпроекты хоть по какому-то признаку. В результате проект становится жутким Legacy. Думаю многим знакомо "Лучше с нуля все переделать".

По итогу мы получаем необходимость в построении дерева, в котором видны четкие зависимости. При этом необходимо все воспринимать именно в масштабе проблемы. Своего рода получается своеобразный механизм отлова ошибок: происходит ошибка/аварийная ситуация/поломка и мы понимаем, что поломалось в определенном узле. Иными словами данную систему легче тестировать. Узлы должны быть изолированы друг от друга и должны быть атомарными. В случае с IT - это называется инкапсуляция. И да, многие знают принципы ООП, но уж очень много специалистов, причем достаточно неплохих, пользуются ими крайне неумело.

Все гениальное просто

Чем проще агрегат, тем меньше шансов его поломать. Не раз слышал от автомобилистов - "там почти ничего нет, потому и ломаться нечему." Если разрабатывается какая-нибудь конструкция, то стоит ее сделать максимально простой. Чем проще конструктив, тем он будет дешевле в обслуживании, тем меньше внимания ему придется уделить, а лишние узлы вводят в заблуждение. Рассмотренная выше система теплоснабжения - один большой сложный узел, которым было тяжело управлять и его регулярно приходилось чинить.

Для начала приведу пример из машиностроения. Открываешь конструкторскую сборку при этом ожидаешь увидеть несколько болтов и гаек, но при этом видишь гремучую смесь узлов, которые вообще должны находится в другом месте в иерархии данного узла. Один элемент соединяется болтом, сопряжения которого выставлены неверно, другой соединяется таким же болтом, но из другого места. Все это взято из разных мест - из сетевой папки, из "Моих документов", а где-то хранится в папке загрузок ибо скачано с noname-сайта.

После того, как проект будет разбит на модули, стоит сделать его максимально понятным для мозгов остальных возможных участников процесса. Лучший вариант, чтобы смог разобраться специалист вашего профиля с минимальным объемом знаний. Мы все чего-то можем не знать. Допустим, вышла какая-то фича у фреймворка или вообще у языка. Не стоит ее применять везде и всюду, если конечно это не дает каких-то неоспоримых преимуществ в виде сокращения строк кода, либо приросте производительности; а доставить коллегам неприятности это вполне может.

По работе мне приходилось сталкиваться с кодом, который был очень "навороченным". В качестве примера - в одном классе могла быть описана бизнес логика большей части проекта, в другом классе один только список инициализации был из более, чем ста параметров, третий был реализацией всех возможных унаследованных интерфейсов. Работать с таким кодом - сущий ад. И действительно - легче переписать с нуля, так как по сути получится как в том анекдоте - только что-то рефачишь - а оно фатально ломается и непонятно почему.

В итоге каждый узел должен быть настолько простым, чтобы его можно было переконструировать без фатальных последствий для всей системы. Отчасти здесь просматривается принцип единственной ответственности SOLID.

Чистота залог здоровья

С моей точки зрения, инженер должен действовать аккуратно и расставлять все по полочкам. Тогда и он, и тот, кто придет ему на смену, будут всегда знать, где что лежит. Например у инженера-конструктора все проекты находятся в одном месте, он всегда знает где и что у него лежит, при этом на любой вопрос в его работе он может ответить. У инженера на производстве все эксплуатационные документы хранятся в организованном виде. Если человек работает за компьютером то все его проекты разбиты по строгой иерархии папок, имена файлов осмысленные и пр.

Сколько раз обращал внимание - если бардак на рабочем столе, то значит и в голове у человека бардак. Как правило и на компьютере у него черт ногу сломит. "Системные" решения такой человек принимать, с большой долей вероятности, не может. Все время он будет делать заплатки на уже еле живой конструкции, которая того и гляди развалится при внесении очередных изменений. Все осложняется тем, что такой инженер может не только сам поломать продукт, но и утянуть за собой других, так как другим придется подстраиваться под смежные решения.

Думаю многие лиды(да и не только лиды) понимают, насколько важен чистый код. Самому же потом поддерживать, а ты не только не помнишь как работает какой-то механизм, но и не знаешь, где посмотреть, чтобы разобраться. Пример из практики, не связанной с разработкой ПО: у инженера на столе лежала кипа проектов, заявлений и пр. бумажек. Минут 10 уходило только на то, чтобы найти нужную. При этом после нахождения кипа не разбиралась. В их работе не было системных решений - были только заплатки. Во время работы на заводе мне в этом плане немного повезло - многие задвижки, вентили и рабочий инструмент, когда я пришел, лежали почти что в строгом порядке. Работать было приятнее.

Без бумажки ты - бедняжка

Документация нужна любому инженеру. Составлять документацию не хочется никому. Сколько я видел закатывания глаз от необходимости переделывать документацию из-за того, что что-то в ней не так написано, что были внесены изменения в какой-то проект и да, этот вопрос действительно мучает многих инженеров. Но... Это необходимо. Если не для тебя, то для кого-то другого точно понадобится. По-дефолту человек не обладает такими качествами, как телепатия, поэтому всегда нужно писать как сделать то-то и то-то. Все должно быть прозрачно и ясно. Причем лично для меня в приоритете стоит ясность изложения, нежели соответствие стандартам.

Заодно пару слов о стандартах. Многие стандарты писались, по моему скромному мнению, именно из тех соображений, что должно быть яснопонятно всем. Делай как написано и будет тебе счастье. К примеру, винты делаем только с левой резьбой и только с таким хим.составом. Как-то спорил с одним инженером, который сказал "Стандарты писали девочки, которые ничего не понимают в технике." Такое было слышать, как минимум, странно. Обычно стандарты рождаются между институтами, ведущими предприятиями промышленности, а потом согласуются этими предприятиями и выпускают эти согласования в бумажном виде, что и является стандартом. То есть есть они нужны не для того, чтобы насолить студентам инженерных ВУЗов, а для четкого взаимодействия их на практике.

Возможно, кто-то скажет что я сам себе противоречу, но я немного перефразирую высказывание из манифеста гибкой разработки: "Документ, по которому удобно и можно правильно работать, важнее исчерпывающего соответствия стандарту". Как-то слышал байку, что в одном ВУЗе висел плакат, на котором нужно было найти 3 ошибки, чтобы получить автомат по предмету. И каждый из выпусков находил что-то новое. К чему это я? Соответствие стандарту - не самоцель. К примеру есть сборочный чертеж, который дает однозначное представление, то инженер свою задачу выполнил.

Были моменты в моей практике, когда я писал стандарт, по которому в дальнейшем работало предприятие. Это была не самая интересная работа. Но, в тот момент, когда я писал этот стандарт, у меня самого все разложилось по полочкам. В момент изложения мыслей на бумаге начинаешь разговаривать сам с собой видеть мысли четче и более структурированно. Я увидел недостатки, как теории, которую я описываю, так и недостатки своей инженерной работы. Она действительно была где-то сделана по принципу тяп-ляпа. Дописав очередную страницу, я решил, что будет правильнее в некоторых местах переделать свою работу по-человечески.

Используй интерфейс как связь между узлами

Вышеописанное описание стандарта напоминает описание интерфейса. Интерфейс - это своего рода также соответствие стандарту. Порой пройдет достаточно много времени, прежде чем ты понимаешь, как нужно было действительно проектировать интерфейс. С интерфейсами мы сталкиваемся постоянно в реальной жизни. Автомобилист не обязан знать устройство двигателя и уметь в нем ковыряться, если конечно это не вменено ему в обязанность. У него есть интерфейс для вождения - руль, педали, ключ зажигания и пр.

Для того, чтобы у нас узлы могли спокойно между собой взаимодействовать, необходимо тщательно продумывать именно интерфейс взаимодействия. Причем в очень многих случаях он даже важнее внутреннего устройства механизма, пускай и очень сложного. Автомобилист может ехать как на электрокаре, так и на автомобиле с ДВС. Человеку по большей части все равно, что под капотом. Шестеренкам, которые передают крутящий момент тоже. Не все равно только шестеренкам на то, как они получают этот крутящий момент. А вот это и есть очередной интерфейс. Только не для человека, а для механизма. В вышеописанной системе теплоснабжения интерфейсом мог бы стать теплообменник.

Еще одним преимуществом интерфейсов я считаю то, что по сути это как контракт на узел. Он должен быть таким-то, чтобы с ним можно было работать. И тем самым мы даем понять другому инженеру, какую ответную часть и как нужно разрабатывать другому инженеру. Я очень часто наблюдал ситуацию, когда разрабатывалась сложная конструкция, а интерфейсам не уделялось должного внимания. Будь то программный код, продукция машиностроения или проект жилого дома.

95% работы - допиливание 5% проекта или лучшее - враг хорошего

Во всех сферах, которых успел поработать, всегда находилось "узкое горлышко" в которое непременно нужно было втиснуться. Речь о юзабельности для бизнеса. К сожалению это наш общий бич. Инженеру ПГС нужно так запроектировать, чтобы в теплоузле разместить оборудование, чтобы и доступ был, и не шумно было, и чтобы температура была допустимая, и денег минимум. Программисту - нужно вписаться в дедлайн, реализовать все хотелки заказчика, и производительность чтобы была, и денег минимум. Системному администратору нужно допилить какой-нибудь jabber-клиент, когда уже все остальное готово, подключить почту внешнего сервиса, чтобы были корректными имена сотрудников, и чтобы это ничего не стоило.

По-другому можно перефразировать все вышеописанное как впихнуть невпихуемое. И так будет всегда. Ужать захотят всегда, в первую очередь по деньгам, затем "по конструкции", поэтому теперь я всегда пытаюсь проектировать так, чтобы было недолго исправлять. Придется всегда делать лучше. Но оно того стоит. Ведь когда-то отказались в автомобилях от запуска с помощью заводной рукоятки в пользу стартера. Автомобилистам это было нужно. Можете представить, чтобы сейчас стали выпускать такие автомобили с рукояткой вместо стартера? Пускай даже автомобили будут неплохими, их вряд ли будут покупать. Почему? Просто уже неудобно будет пользоваться в сравнении с другими автомобилями.

В данном случае речь идет о том, чтобы сделать проект лучше, удобнее, так чтобы голова у конечного потребителя не болела ни о чем, касаемо Вашей работы. Но тут нужно соблюсти очень тонкую грань между хотелками потребителя - "хочу, потому что я дурачок" и "хочу, потому что действительно нужно". Тут уже нужно экспертное мнение и только оно. И да, эксперта найти нелегко.

Вместо заключения

По большей части данный момент олицетворяет мои фантазии, как инженера. На мой взгляд на данный момент инженерам не хватает инструментов "оркестрирования" их системами. Есть, правда, зачатки данных систем: у разработчиков ПО - это UML-кодогенераторы; у инженеров-проектировщиков ПГС - это BIM, у инженеров-проектировщиков в машиностроении PLM-системы. К сожалению многие из этих "продуктов" очень медленно развиваются, хотя потенциал у них больше, чем даже думают их создатели и их очень не хватает инженерам "высокого уровня".

Но это происходит по той причине, что конечные пользователи "не умеют их готовить" и, как причина следствие "продукт" не развивается из-за отсутствия фидбека. Из своих нынешних коллег кодогенератор использую только я. Остальные UML рисуют на бумажке, которую потом просто выбрасывают. Следующему разработчику, которому отдают проект, приходится вникать во многие детали и, если проект большой, общую картину он увидит не скоро. А ведь UML более нагляден, нежели банальное чтение кода. Даже для тех, кто далек от разработки. И как плюшки - часто дает возможность для самодокументирования кода.

PLM-системы дают возможность не только хранить как в файлопомойке общем хранилище инженерных изделий, они также могут вытягивать информацию для менеджмента (опять же своего рода самодокументирование). Но главное - у нас появляется возможность оркестрировать сборками "верхнего уровня" в некой виртуальной среде, повторно использовать разработанные на других проектах узлы. Наблюдая за сборками конструктора-джуна в PLM системах, могу сказать, что для него это действительно просто хранилище несвязных данных. В худшем случае на практике это касается и конструктора-сеньора.

Своего рода при присутствии недостающего определенного функционала у вышеуказанных систем можно не спускаться до узлов более низкого уровня. Тут мы абстрагируемся настолько, насколько возможно. Своего рода это проектирование "сверху вниз". Мы должны описать своего рода контракт. Инженер, который будет проектировать узел более низкого уровня, будет ограничен в своей рукожопости данными необходимыми для разработки. Хотелось бы видеть больше абстракции в подобных продуктах, где у архитектора системы нет необходимости(или возможности) вникать в детали проектируемых абстракций.

Пускай пока подобных инструментов даже не предвидеться в будущем (хотя потенциал есть), хотелось бы видеть в мышлении рядового инженера больше абстракций. Ну или хотя бы, чтобы он к этому стремился - не боялся разделять сложную систему и принимать системные решения. Если в работе много технически-сложных вопросов, то стоит посидеть, пораскидать на бумажке, банально порассуждать наедине с самим собой. И не бойся ошибиться - не ошибается только тот, кто не работает.

Чуть не забыл - да начнется срач ;)

Статья раскрывает тему прямых и косвенных механизмов развития сотрудников и продуктовых команд внутри компании. К прямым механизмам относятся коучинг, менторство, терапия, тренинг и консультация, спонсируемые и поддерживаемые на уровне руководства компании. К косвенным относятся такие механизмы, как культура фасилитации встреч и мероприятий, а также проявляемые стили управления в зависимости от ситуации. Проявление косвенных механизмов зависит от знаний и опыта сотрудников с руководящей функцией как лидера мнения.

В статье предложена система метрик для измерения и дальнейшего анализа атрибутов сложившейся системы развития сотрудников внутри организации.

Остальные части программы оценки готовности к трансформации:
SCRUM: Понимание и применение фреймворка
SCRUM: Разработка и поставка продукта
SCRUM: Гибкое управление продуктовыми направлениями

Фасилитация встреч и мероприятий

Способ и характер организации встреч внутри группы людей определяет возможность личностного и командного роста. Фасилитация - искусство направления групповой дискуссии в конструктивное и продуктивное русло. Фасилитатор отвечает за планирование и организацию необходимого процесса, когда как группа людей отвечает за предоставление содержания с учетом своей экспертизы. Фасилитация помогает организовать события ориентированные на достижение цели в рамках эффективного использования времени, а также вовлечения участников в дискуссию (предоставление возможности всем высказать свое мнение, создание атмосферы где можно быть услышанным, создание атмосферы где владеешь принятыми решениями).

[ 0 - 19] - низкий результат, характеризующий слабо развитую культуру фасилитации событий в компании. При данном результате выделяется директивный способ организации, целью которого является трансляция задач от сотрудников с руководящими функциями без процессинга и обсуждения с исполнителями. Рекомендуется разработать программу в разрезе культивации философии фасилитации на уровне среднего менеджмента компании.

[20 - 25] - высокий результат, характеризующий устоявшуюся культуру фасилитации событий внутри компании, целью которой является создание удобных механизмов для владельцев содержания. Данный способ организации событий предоставляет модель встреча-развлечение, на которой у участников формируются доверительные отношения, целеполагание и вовлеченность в ожидаемый результат. При данном результате рекомендуется сделать акцент на развитие личностных характеристик сотрудника с функциями фасилитатора.

---

Методы развития продуктовых команд

Наличие в компании гибкой системы практик личностного и командного роста позволяет сформировать и укрепить устойчивую позицию HR-бренда, в которой сотрудник видит горизонт своего развития в контексте развития компании. Можно выделить следующие методы развития продуктовых команд:

1. Коучинг - метод тренировки, в процессе которой, устанавливаются цели для достижения. В свою очередь, коуч-тренер помогает команде достигнуть данные цели, используя знания предметной области, навыки межличностного общения и фасилитации.

2. Менторство - метод тренировки, при которой, происходит трансляция шаблона знаний и опыта от спонсора-ментора для формирования необходимых паттернов профессионального поведения. Для успешной реализации данного метода, необходимо наличие у ментора ярко выраженной экспертизы в предметной области и лидерские качества.

3. Терапия - метод, позволяющий сотруднику или продуктовым командам снять с себя психологические или физические симптомы профессиональной нагрузки с помощью выстроенного доверия и возможностью быть услышанным.

4. Тренинг - метод, при котором эксперт в предметной области делиться своим знанием и опытом с применением разработанных методических материалов. Целью данного процесса является предоставление новых знаний и инструментов для группы сотрудников за короткий промежуток времени.

5. Консультация - метод, позволяющий функциональным подразделениям компании или продуктовым направлениям получить независимую оценку эксперта для решения бизнес проблемы в части организации работ производственных направлений.

[ 0 - 10] - низкий результат, характеризующий отсутствие у компании осмысленного подхода к развитию и адаптации кадров. В случае динамической среды стартапа, может наблюдаться эмоциональное выгорание сотрудников на горизонте испытательного срока; в случае умеренной корпоративной среды, наблюдается проявление низкой культуры развития сотрудников, как осознанный выбор компании для снижения затрат рынка низкотехнологичной продукции. При данном результате, целесообразность разработки программы обусловлена видением инвесторов в части долгосрочности нахождения компании на рынке, а также высокотехнологичностью продукции.

[11 - 20] - средний результат, характеризующий ограниченный набор методов развития продуктовых команд или не системность их использования. В случае динамической среды стартапа, может наблюдаться эмоциональное выгорание сотрудников на горизонте одного года; в случае умеренной корпоративной среды, может проявляться фрустрация и стагнация в развитии профессиональных навыков и знаний у сотрудников. В первую очередь, рекомендуется сделать акцент на развитие менторства и системы тренингов для сотрудников.

[21 - 25] - высокий результат, характеризующий зрелую систему развития и поддержки продуктовых команд. В арсенале компании имеются все доступные методы для формирования у сотрудников необходимого проактивного паттерна отношения к труду, новых навыков и знаний. При данном результате, компания осознаёт необходимость инвестицией в человеческий ресурс, так как он является потенциалом роста продуктовых направлений. Рекомендуется рассмотреть создание образовательного комплекса (аналоги GeekBrains, SkillFactory и т.д.) в периметре компании в целях становления и развития кадрового резерва.

---

Стили управления

Подходы и стили лидерства определяют развитие команд в сторону директивного и процедурного или кооперативного и творческого взаимодействия. В силу того, что лидеры являются агентами изменений, их особенности личности и темперамента будут проецироваться на выстраиваемые процессы в продуктовой команде. Компании необходимо тщательно относиться к подбору сотрудников с руководящими функциями с позиции ярко выраженных стилей лидерства.

Определение интегральной шкалы оценки свойства стили лидерства не целесообразно, в связи с тем, что каждый стиль имеет место быть в зависимости от конъюнктуры и ниши рынка, которую занимает компания.

Стоит отметить, что для компаний-стартапов, специализирующихся на выпуске новых продуктов на рынок для поиска устойчивой бизнес модели необходимо иметь самоорганизующуюся рабочую среду с идеологией, креативностью и свободой мысли. Для создания и поддержки данной среды, отлично подойдут лидеры мнения со следующими стилями: стиль идеолога, стиль слуги, стиль трансформатора, стиль темпа.

В свою очередь, компании, нащупавшие устойчивую бизнес модель для своего продукта начинают искать возможности для его масштабирование на новые рынки и новых клиентов. Для осуществления данных целей, хорошо подойдут следующие стили лидерства: стиль коуча, стиль невмешательства, стиль демократа по отношению образованных продуктовых команд на этапе стартапа.

Для развития продуктовых команд, противопоказано иметь лидеров с ярко выраженными стилями: стиль автократа, стиль операционный, стиль бюрократа. Данные стили будут сдерживать развитие продуктового направления и развитие самоорганизующихся команд из-за особенностей внутренних качеств лидера.