Польза должностной инструкции

В фирме появляется задача по разработке должностных инструкций. На одного из руководителей падает эта «почетная обязанность». Как вынести пользу из этой формальной задачи?

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

Как правило исполнитель тратит 5 минут на гугление примеров и скачивает чужой шаблон с авторскими ошибками и особенностями той другой организации. В другом случае автор пишет «отсебятину» вводя собственную терминологию и систему, рождая инструкцию в творческих муках. Формально задача вроде бы решена, все довольны, не так ли?

Я тоже одно время ломал голову над задачкой, пока не нашел другой, правильный подход. IEEE разработала документ – 📚 Software Engineering Competency Model (SWECOM). 👉Далее...

@aheadofthepack

Продуктовая и проектная диверсификация

Любой стартап стартует с одного проекта или продукта в варианте MVP. Исходя из статистики 70-90% запусков терпят неудачу в силу массы причин. Почему? Срабатывают риски, которые не удалось или было невозможно оценить на входе. Большинство предпринимателей понимают это, но вместе с тем, будучи оптимистами, не отказываются от такой затей, т к и выгода в случае успеха может быть немалой.

Допустим запуск прошел успешно. 🚀 Появился один ключевой заказчик для проектов, либо продукт попал свою целевую нишу. Менеджмент компании, решает, что ухватили чёрта за хвост и пора делить бенефиты. Как правило в этот момент или чуть позже срабатывают риски. 🎲

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

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

Диверсификация необходима. При проблемах в одном из продуктов или проектов весь портфель пострадает не так значительно, сохраняя устойчивость компании.

@aheadofthepack

Возврат к средней величине

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

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

Вы видите это в числах, если внедрены "показометры" производительности, KPI или что-либо еще. Как пример, метрика Velocity в методологии Scrum.

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

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

@aheadofthepack

Зацикленность на технологиях

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

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

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

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

@aheadofthepack

Сегодня у нас видеопредставление спикера!
Александр Кузовлев
Руководитель проектов,
ВА\SA аналитик в Третий Пин – агентство разработки электроники и встроенных систем на заказ, – рассказал про свое выступление 17 декабря 2020 года на Аналитическом марафоне #3:

https://youtu.be/zFHXM_6AFOs

Причем тут Маслоу?

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

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

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

@aheadofthepack

Встреча совсем скоро

Я буду выступать на Третьем Аналитическом марафоне 17 декабря с докладом «Польза и вред от технического долга в аналитике». Несмотря на плотный график и яростные попытки вирусов подорвать приготовления, все сделано, и встреча состоится послезавтра.

Я подниму тему, с которой все сталкивались не единожды, и которая не раз приводила в уныние не одну команду разработки. Все мы сталкивались с ситуацией, когда надо срочно ускоряться, разрабатывать спецификации, писать код, выпускать релизы. Начальство говорит: «Давай, давай»! Но сделать ничего быстро не получается. Груз накопившихся в разработке проблем давит на плечи. И мы занимаемся переделкой ранее сделанной работы. Нас настиг Техдолг 💣

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

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

@aheadofthepack

Ощущения не менее важны функциональности

Популярным инструментом Канбан-доской пользуются все больше и больше команд. В одной из прошлых компаний наша переговорка со стеклянными стенами была увешена десятками если не сотнями разноцветных стикеров. Общую картину разработки можно было оценить быстро – одним взглядом. Но как же было неудобно поддерживать этот физический инструмент. То маркеры не пишут, то стикеры нужного цвета не закуплены, то обнаружится разработчик с «медицинским подчерком», то начинается внезапный стикеропад. Муторное это дело. Сейчас же постоянно кто-то на удалёнке, поэтому нашли аналогичный виртуальный инструмент и перешли на него.

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

Проблема UX решилась рисованием своей собственной доски в том же инструменте с нормальными объектами типа стикер. Теми самыми разноцветными квадратиками, отбрасывающими тень на доску непроклеенным краем. Эх этот ламповый UX… Странно, что разработчики инструмента так не чувствуют.

@aheadofthepack

Писать в стол не модно

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

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

И что в итоге? Заигравшись в этом интересном процессе, я начал утрачивает интерес к своему произведению. А потом и вовсе кинул статью "в стол" никуда в итоге не опубликовав.

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

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

@aheadofthepack

Меняющиеся походы самообучения

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

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

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

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

Еще до проведения опроса заглянул в исследование Медиапотребление в России 2020, которое провела Delloite. Если покопаться, в нем можно найти, что за последний год охват чтения печатных книг снизился на 14%, а электронных не вырос. Рискну экстраполировать эту печальную тенденцию и на остальные области получения фундаментальных знаний.

Даже не смотря на малую выборку, этот тренд был заметен и у нас в фирме. По сравнению с 2019, в 2020 году читать стали меньше. При этом значительно меньше стали дочитывать книги до конца. Из-за чего это происходит писал в прошлом году в посте Два подхода к чтению книг. Однако не все так печально. Айтишники начали больше времени тратить на участие в легких формах обучения: семинарах, конференциях, митапах. Теперь понятно куда уходило время, и что делать EdTech-компаниям и предпринимателям. ;-) Хотя я считаю, что такие формы обучения прогрессивны, но недостаточны. Их крайне желательно подкреплять чем-то еще из классической тяжелой артиллерии.

@aheadofthepack

Обещать - не значит жениться!

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

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

Давайте посмотрим откуда берется такое непонимание и разница в расчетах?

Возможно дело в «проектном мышлении». Проектное мышление пропускает массу вопросов, не входящих в перечень задач:

✔️Сколько стоил непрерывный маркетинг продукта, исследования рынка конкурентов на протяжении его жизненного цикла?
✔️Сколько стоили неудавшиеся эксперименты и проверки гипотез?
✔️Сколько стоила цепь непрерывных улучшений продукта после получения обратной связи от пользователей?
✔️Сколько стоила поддержка клиентов, как только продукт прошел в продакшн?
✔️ Сколько стоила дистрибьюция и продажи?
✔️…

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

На старте продуктовой разработки нет такой «реперной точки», обозначенной в будущем, в которой можно собраться и сказать: «Все молодцы! Мы хорошо поработали. Продукт сдан. Расходимся».
Когда-то в будущем действительно наступит момент, в котором расчеты и прогнозы покажут, что действительно пора принимать решение о сворачивании поддержки и вывода продукта из цикла разработки и производства. Но наперед эта точка заведомо неизвестна, как и неизвестны все развилки, которые приведут продукт в эту точку. Соответственно в разработке продукта заранее неизвестно сколько средств будет потрачено на это все. Именно поэтому, если взять бюджетный срез всех продуктовых активностей и приравнять это к проектному бюджету ничего хорошего не выйдет.

@aheadofthepack

Бег за Лидером

Вы смотрели соревнование по легкой атлетике по бегу на средние дистанции?

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

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

Можно ли оставаться лидером на протяжении длительного периода в конкретных условиях? Да, возможно имея уникальное преимущество. Но это уже другая история.

@aheadofthepack

Минимальные продукты

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

С концепцией - Минимально жизнеспособный продукт (MVP) сталкивалось, наверное, большинство, кто изучал или применял продуктовый маркетинг. Формулирование первоначального определения приписывают Фрэнку Робинсону. Позднее идею подхватил и популяризировал Эрик Рис и его термин мне нравится больше. MVP - версия нового продукта, которая позволяет команде собрать как можно больше проверенной информации о клиентах с наименьшими усилиями. У MVP существуют и «близкие родственники». 😊

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

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

Еще одно интересное определение - Минимальный привлекательный продукт (Minimum Loveable Product, MLP). Концепцию придумал Кэт Нуун, введя понятие продукта, который будет не только решать проблемы пользователей, но и устанавливать с ними эмоциональную связь. В предложенной концепции на передовую выходят не просто важные функции, или те, за которые пользователь готов заплатить, а опыт пользования. Это может быть дизайн, эстетика, удобство использования, например скорость работы или плавность изменения экранов. Пользователь уже имеет опыт с похожими альтернативами и минимальной функциональностью его уже так просто не зацепить. MLP позволят дифференцировать продукт на уже занятом рынке.

Как видно каждый смотрит на концепцию под своим углом.

@aheadofthepack

Минимальные продукты (продолжение)

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

📚 Марти Каган «Вдохновленные»
📚 Скотт Хёрф «Как создать продукт, который полюбят»
📚 Роман Пихлер «Управление продуктом в Scrum»
📚 Марка Денна и Джейн Клиленд-Хуан «Software by Numbers»
📚 Эрик Рис «Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели»

Если кто-то может дополнить мою подборку, прошу в комментарии.

Режим управленческого автопилотирования

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

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

Тоже самое происходит и в продуктом или проектом управлении. Действия в стандартных ситуациях часто совершаются на автопилоте. А что, если замедлиться и спросить себя: «Почему было принято такое решение в конкретной ситуации?» Впадаешь в ступор: «Как почему?» Это первое решение, которое пришло в голову. Мозг мгновенно предложил его на основании предыдущего опыта решения схожих задач. У нас уже выработался некоторый паттерн принятия решений. Для большинства всплывающих задач это здравый подход. Неспроста постоянно появляются шаблонизированные фреймфорки, подходы и методы. Они помогают работать паттернами, выработанным не на собственной шкуре, а позаимствовав чужой обкатанный опыт.

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

Режим «автопилот» работать не будет если:
✔️ Необходимо виртуозно разрулить проект в нестандартных условиях с ограниченным лимитом времени-денег-ресурсов
✔️ Меняется технологический стек
✔️ На порядок увеличивается масштаб чего-либо
✔️ Если суммарные риски начинают превышать выработанные контролируемые значения
✔️и т д.

В итоге основная задача – это понять в какой ситуации сейчас находимся: в стандартной или не стандартной.

@aheadofthepack

Политика Открытых ушей

Политика открытых дверей - распространённая практика донесения обратной связи по восходящей линии в организации. Большинство компаний с демократичным подходом к управлению не забывают о ней.

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

👉 Подробнее в статье на vc

Системный подход vs нафигачить

Большинство IT-компаний начинают с малого. Часто с хаотического процесса, держащегося на здравом смысле и воле основателей. Если компания перерастает период «младенческой смертности», начинается осознание не только что нужно делать, но и как нужно делать. В процессе эволюционного развития R&D начинают вводить сложные процессы. При таком подходе становится возможным создавать серийное, масштабное и долгоиграющее; обрести устойчивость и повторяемость результатов разработки продукта или услуги. Происходит постепенное обрастание детальным BA/SA, сложным процессом CI/CD, полным QA automation и т д. Разработка становится неповоротливой, наподобие перекаченного атлета.

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

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

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

@aheadofthepack

Насильственное обучение

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

Как организовать обучение внутри команды правильно? Практика показывает, что "насильственное" обучение людей дает невысокую эффективность.

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

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

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

💡Почаще проводите интервью с командами и индивидуально, вы узнаете много нового.

@aheadofthepack

Делать как для себя

Редко, когда разработка железа, ПО, да и любая работа, идет не в команде. Разработчиков отшельников в расчет не берем. 😋 А где команда, там появляются цепочки процессов. Не важно описанные они или образовались и зафиксировались естественным путем. Но стоит помнить о том, что же будет дальше с результатами труда каждого участника? Подкреплю примерами из жизни.

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

Либо ситуация, наоборот. Тестировщик или кто-то другой нашел в работе ПО ошибку. Название бага в системе багтренинга записал, но остальные обязательные поля заполнить поленился. Следующий, кому попадет эта задача возможно потратит не один час, пытаясь понять и воспроизвести проблему.

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

Либо совсем элементарный пример. Принимает кто-то ценный груз, но коробку после вскрытия запаковывает кое-как. Следующий взявший ее со склада, не зная подвоха с непроклеенным дном, разумеется, уронит и повредит товар.

Эти примеры всего лишь из внутренних процессов. Когда что-то уходит за пределы команды вариации возрастают.

Думаю, всегда стоит подумать:
⚽️ Кто стоит следующий в цепочке действий?
🏀 Хватает ли ему знаний о том, что было сделано?
🏐 Как облегчить ему работу?
🏉 Как бы я хотел, чтобы мне передали задачу?

Классно замечать, как люди учатся на своих и чужих ошибка и постепенно начинают относиться к делам вдумчиво.

@aheadofthepack

Полезный и вредный технический долг ч.1

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

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

🎯 Экономия ресурсов. Прежде всего - капитала. Молодой фирме крайне желательно как можно быстрее проверить продуктовые гипотезы. Как можно быстрее вывести минимально жизнеспособный продукт MVP на рынок и запустить новый цикл разработки. При этом минимизировать первоначальные затраты. Физических ресурсов, ни тем более денежных у фирмы может и не быть. Основатели стартапа, вынуждены экономить ресурсы. Почему? Все просто - вероятность успеха, особенно в новой области невысока. Поэтому взятие техдолга – это большая экономия стартапов на старте. Лучше за меньшие деньги отработать как можно больше гипотез.

🎯 Уменьшение времени появления и модификации продукта, либо инкременты проекта. Time to Market – не менее важный показатель для стартапов. Для средних и крупных организаций такое тоже может быть, но в менее выраженной форме. Обычно для корпораций более важно качество, т к присутствуют уже сформировавшаяся аудитория и соответствующие репутационные и прочие риски.

🎯 Устранение ненужных трат. Классический случай - старые продукты, жизненный цикл которых подходит к концу. В них уже вряд ли будет какое-либо развитие. Поэтому разумно начинать накапливать технический долг. Нет смысла вылизывать внутреннюю кухню до блеска, можно и оставить/приделать костыли напоследок.
Еще один пример – это проекты без продолжения. В проектах с фиксированным бюджетом и соответствующим перечнем работ бывает нет никакой возможности расширить ни первое, ни второе. Поэтому приходится загрублять качество, внести риск в виде соответствующего техдолга.

А если коротко, описанные случаи намеренного появления техдолга приводят к краткосрочной экономии двух вещей – времени и денег.

@aheadofthepack

Полезный и вредный технический долг ч.2

Продолжу писать заметки по актуальной теме.

Технический долг может быть достаточно дешев в краткосрочной перспективе. Распространенный пример полезного использования техдолга — создание различных прототипов. Большинство новых продуктов как раз с этого и начинается.

Чтобы реализовать MVP необходим минимум технической и тестовой документации и полезных процессов. Для Proof of concept (PoC) технического долга можно набрать еще больше. Важно лишь зафиксировать что конкретно хотим проверить (наши гипотезы) и какими методами, чтобы потом не создавалось искажений при интерпретации результатов. Думаю, многие согласятся с Agile подходами. Работающий прототип и быстрая проверка результата более важна чем наличие правильной полной документации и отлаженного процесса. Работающее MVP является ценностью для пользователей, PoC для команды разработки или инвестора. При этом использование долга происходит наиболее эффективным образом. Об этом я уже писал недавно в посте Системный подход vs нафигачить

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

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

@aheadofthepack