Всем привет. Меня зовут Максим Никитин, я занимаюсь разработкой ИТ-решений больше 20 лет. За это время я был на всех ролях данного процесса - от программиста до владельца собственной студии разработки ИТ-продуктов. Ко мне в студию приходили заказчики с совершенно разными задачами и абсолютно разным ИТ-бэкграундом. Я сам искал подрядчиков на мелкие задачки и проекты, которые нерентабельно было делать командой студии. Побывав по разные стороны баррикад, я готов поделиться своим опытом. В первую очередь именно с теми, кто готов решать проблемы своего бизнеса ИТ-решениями. С заказчиками, владельцами, стейкхолдерами - всеми теми, кто хотел бы управлять ИТ-решениями зряче.
Менеджеры проектов и продуктов, думаю, тоже найдут пользу в моих историях. Хотя бы для того, чтобы прокачать "насмотренность". Ведь каждый продукт и команда уникальны. А значит, нужно знать очень много разных методы и способов, чтобы выбрать в конкретной ситуации оптимальный.
Надеюсь, что мой блог и канал помогут сделать разработку ИТ-продуктов вкусной, а не беготней с выпученными глазами от адского жжения. 🙂
—
Оставлять комментарии можно в блоге https://itpepper.mnikitin.ru/forwhat
Менеджеры проектов и продуктов, думаю, тоже найдут пользу в моих историях. Хотя бы для того, чтобы прокачать "насмотренность". Ведь каждый продукт и команда уникальны. А значит, нужно знать очень много разных методы и способов, чтобы выбрать в конкретной ситуации оптимальный.
Надеюсь, что мой блог и канал помогут сделать разработку ИТ-продуктов вкусной, а не беготней с выпученными глазами от адского жжения. 🙂
—
Оставлять комментарии можно в блоге https://itpepper.mnikitin.ru/forwhat
Teletype
Круто ты попал на...
Привет, я Максим Никитин. В этом посте ты узнаешь, чем тебе может быть полезен мой блог
Продут или проект?
Холивар нужен для того, чтобы среди множества правильных ответов найти красивый 🙂 Отличия подходов, плюсы и минусы - мой взгляд на тему.
Давайте представим, что милая барышня решила завоевать сердце мужчины, воспользовавшись народной мудростью "Путь к сердцу мужчины лежит через его желудок". Как бы она действовала, выбери проектный подход? Правильно - конечно же составила бы план. Как без него. Итак, план:
1. Узнать, что любит мужчина - мясо или брокколи (правильный ответ, конечно же, мясо! 🙂 )
2. Сходить на кулинарные курсы
3. Приготовить самое вкусное мясо, чтобы уж точно поразить в самое сердце.
А как бы поступила барышня, выбери она продуктовый подход? Да просто бы попробовала. Приготовила бы - как умела, мясо и брокколи и посмотрела бы на реакцию. Брокколи попало бы явно ниже сердца, а вот мясо вполне могло бы открыть дорогу именно к сердцу.
Думаю, этого простого примера достаточно, чтобы понять разницу в подходах. Ключевые отличия сосредоточены в двух точках:
- Способ снижения риска "сделать не то" - не попасть в желаемую цель
- Отношения к изменениям в процессе работы
В проектном подходе мы снижаем риски максимально полной и подробной проработкой задачи на старте. Соответственно, отношение к изменениям в проекте максимально негативное. И не потому, что менеджер - бессердечная скряга. А потому что по ходу проекта не будет достаточно времени на проработку новой вводной. И риск не попасть в цель работ с каждым изменением растёт в геометрической прогрессии.
В продуктовом подходе риски снимаются за счет быстрых и недорогих итераций разработки и получением обратной связи от рынка или ключевых пользователей. Отношение к изменениям - максимально позитивное. Собственно, в них и состоит сила продуктового подхода - показатель time2market (время от возникновения бизнес-идеи до её первого воплощения в доступном для бизнес-пользователей виде) недосягаемо выше, чем у проектного подхода. А значит, ИТ-продукт будет успевать за бизнесом, который требует постоянных изменений.
Минусы проектного подхода очевидны:
- Заведомо низкий time2market - на детальную проработку, расшитие неопределённостей и согласования решения со стейкхолдерами занимает много времени
- Следствием низкого time2market становится увеличение общего количества рисков, могущих негативно повлиять на проект (представьте, что в нашем примере пока первая барышня занималась на курсах освоением техник прожарки стейков, другая барышня просто пришла бы к юноше с тортиком 🙂 )
- Высокий риск к концу проекта получить ситуацию, когда знания на начальной фазе проекта не соответствуют той ситуации, которая окажется в конце проекта (либо знания устарели, либо собирали знания с "экспертов", а не с реальных пользователей)
Продуктовый подход тоже имеет минусы:
- Риск ухудшить ситуацию новым изменением; причём, по разным направлениям - по функционалу, по дизайну или взаимодействию, по скорости работы. Этот минус является следствием скорости выхода новых фич.
- Риск замучать пользователей постоянными изменениями. Особенно это значимо в В2В-сегменте. Люди привыкают быстро, любое изменение - время на переучивание плюс страх "а если не пойму, не освою, меня же уволят". В итоге либо не будет качественной обратной связи, либо раздувается объем спринта\релиза, а с увеличением объема спринта риск "сделать не то" растёт в геометрической прогрессии.
Ну и резюмирую рекомендациями, когда какой подход стоит применять:
- Проектный подход берём в том случае, если на входе есть достаточное количество подтверждённых актуальных данных. И в том сегменте, где конкуренты позволяют иметь низкий time2market
- Продуктовый подход рулит в ситуациях, когда делаем что-то новое, когда нет явного аналога или накопленного опыта в виде формализованных знаний. И в том сегменте, где time2market не только имеет смысл, но ещё и достижим, с учётом необходимости пользователям часто осваивать что-то новое
Делайте выбор зряче!
Похоливарить в комментах можно в моём блоге: https://itpepper.mnikitin.ru/project-vs-product
Холивар нужен для того, чтобы среди множества правильных ответов найти красивый 🙂 Отличия подходов, плюсы и минусы - мой взгляд на тему.
Давайте представим, что милая барышня решила завоевать сердце мужчины, воспользовавшись народной мудростью "Путь к сердцу мужчины лежит через его желудок". Как бы она действовала, выбери проектный подход? Правильно - конечно же составила бы план. Как без него. Итак, план:
1. Узнать, что любит мужчина - мясо или брокколи (правильный ответ, конечно же, мясо! 🙂 )
2. Сходить на кулинарные курсы
3. Приготовить самое вкусное мясо, чтобы уж точно поразить в самое сердце.
А как бы поступила барышня, выбери она продуктовый подход? Да просто бы попробовала. Приготовила бы - как умела, мясо и брокколи и посмотрела бы на реакцию. Брокколи попало бы явно ниже сердца, а вот мясо вполне могло бы открыть дорогу именно к сердцу.
Думаю, этого простого примера достаточно, чтобы понять разницу в подходах. Ключевые отличия сосредоточены в двух точках:
- Способ снижения риска "сделать не то" - не попасть в желаемую цель
- Отношения к изменениям в процессе работы
В проектном подходе мы снижаем риски максимально полной и подробной проработкой задачи на старте. Соответственно, отношение к изменениям в проекте максимально негативное. И не потому, что менеджер - бессердечная скряга. А потому что по ходу проекта не будет достаточно времени на проработку новой вводной. И риск не попасть в цель работ с каждым изменением растёт в геометрической прогрессии.
В продуктовом подходе риски снимаются за счет быстрых и недорогих итераций разработки и получением обратной связи от рынка или ключевых пользователей. Отношение к изменениям - максимально позитивное. Собственно, в них и состоит сила продуктового подхода - показатель time2market (время от возникновения бизнес-идеи до её первого воплощения в доступном для бизнес-пользователей виде) недосягаемо выше, чем у проектного подхода. А значит, ИТ-продукт будет успевать за бизнесом, который требует постоянных изменений.
Минусы проектного подхода очевидны:
- Заведомо низкий time2market - на детальную проработку, расшитие неопределённостей и согласования решения со стейкхолдерами занимает много времени
- Следствием низкого time2market становится увеличение общего количества рисков, могущих негативно повлиять на проект (представьте, что в нашем примере пока первая барышня занималась на курсах освоением техник прожарки стейков, другая барышня просто пришла бы к юноше с тортиком 🙂 )
- Высокий риск к концу проекта получить ситуацию, когда знания на начальной фазе проекта не соответствуют той ситуации, которая окажется в конце проекта (либо знания устарели, либо собирали знания с "экспертов", а не с реальных пользователей)
Продуктовый подход тоже имеет минусы:
- Риск ухудшить ситуацию новым изменением; причём, по разным направлениям - по функционалу, по дизайну или взаимодействию, по скорости работы. Этот минус является следствием скорости выхода новых фич.
- Риск замучать пользователей постоянными изменениями. Особенно это значимо в В2В-сегменте. Люди привыкают быстро, любое изменение - время на переучивание плюс страх "а если не пойму, не освою, меня же уволят". В итоге либо не будет качественной обратной связи, либо раздувается объем спринта\релиза, а с увеличением объема спринта риск "сделать не то" растёт в геометрической прогрессии.
Ну и резюмирую рекомендациями, когда какой подход стоит применять:
- Проектный подход берём в том случае, если на входе есть достаточное количество подтверждённых актуальных данных. И в том сегменте, где конкуренты позволяют иметь низкий time2market
- Продуктовый подход рулит в ситуациях, когда делаем что-то новое, когда нет явного аналога или накопленного опыта в виде формализованных знаний. И в том сегменте, где time2market не только имеет смысл, но ещё и достижим, с учётом необходимости пользователям часто осваивать что-то новое
Делайте выбор зряче!
Похоливарить в комментах можно в моём блоге: https://itpepper.mnikitin.ru/project-vs-product
Teletype
Продут или проект?
Холивар нужен для того, чтобы среди множества правильных ответов найти красивый :) Отличия подходов, плюсы и минусы - мой взгляд на тему.
В любом холиваре, в любом затянувшемся споре есть то, что остаётся за кадром, но это именно то, что и приводит к отсутствию решения на протяжении долгого времени. Это точка приложения усилий. Чем разнообразнее те, кого мы пытаемся свести воедино, тем сильнее сопротивление. Представьте себе батут, размер которого зависит от этого разнообразия. Причём, не сколько от разнообразия результатов - всегда можно найти высокоуровневый результат, который будет по душе почти всем, - сколько про разнообразие самих людей, которые будут пользоваться вашим решением. От их привычек, взглядов, стереотипов. И чем больше площадь батута, тем больше силы нужно приложить к нему, чтобы выполнить какой-то пируэт, а не просто барахтаться у поверхности.
Сила - обычно, величина постоянная - это наши возможности. Их можно прокачивать, развивать, увеличивать. Но это долго, дорого и всегда имеет предел. Если у вас накопился большой пул задач, который требует увеличения силы для их реализации - больше людей в команде, больше денег, больше времени, больше знаний, то попробуйте поменять точку приложения усилий:
Сфокусируйтесь только на данных, которым будет пользоваться ваше решение. Получать от пользователей, хранить, показывать пользователю
Сделайте обобщённую модель данных - объекты, атрибуты, взаимосвязи
Сделайте неуниверсальное решение для одной только группы пользователей
Добавьте функций для другой группы так, чтобы модель данных не поменялась
Повторите столько раз, сколько было разных мнений.
Таким образом вы сможете управлять получением одинакового результата при разности процессов. И двигаться вперёд уже теми силами, которые есть у вас сейчас.
Кейс из практики читайте в продолжении истории в моём блоге
https://itpepper.mnikitin.ru/point-of-stranger
Сила - обычно, величина постоянная - это наши возможности. Их можно прокачивать, развивать, увеличивать. Но это долго, дорого и всегда имеет предел. Если у вас накопился большой пул задач, который требует увеличения силы для их реализации - больше людей в команде, больше денег, больше времени, больше знаний, то попробуйте поменять точку приложения усилий:
Сфокусируйтесь только на данных, которым будет пользоваться ваше решение. Получать от пользователей, хранить, показывать пользователю
Сделайте обобщённую модель данных - объекты, атрибуты, взаимосвязи
Сделайте неуниверсальное решение для одной только группы пользователей
Добавьте функций для другой группы так, чтобы модель данных не поменялась
Повторите столько раз, сколько было разных мнений.
Таким образом вы сможете управлять получением одинакового результата при разности процессов. И двигаться вперёд уже теми силами, которые есть у вас сейчас.
Кейс из практики читайте в продолжении истории в моём блоге
https://itpepper.mnikitin.ru/point-of-stranger
Teletype
Точка приложения силы
В любом холиваре есть точка, к которой прикладывают силу его участники. Как поменять эту точку и получить решение
Это создаст проблемы
Из невольно подслушанного на кухне: "Если мы это сделаем, то опять будут жаловаться вот на это, а значит, да ну его нафиг". Мы люди и мы склонны принимать комфортные для себя решения. Но, зачастую, этот комфорт ведёт к тому, что мы не принимаем решений, которые серьезно что-меняют. Мы остаёмся к привычном круге проблем и решений. Это очень понятно - в этом меньше риска и меньше трудозатрат.
Избежать "ловушки обыденности", просто, если сначала сопоставить масштабы влияния изменения и масштаб влияния проблем. Если тех, кому изменения принесут ценность, ощутимо больше тех, кому принесут проблемы, значит, можно рисовать диаграмму Исикавы и оценивать пути решения новых проблем.
Стоит помнить, что любое решение для кого-то будет хорошим, для кого-то плохим. "Оптимум" - это когда при прочих равных влияние недовольных на продукт минимально.
Из невольно подслушанного на кухне: "Если мы это сделаем, то опять будут жаловаться вот на это, а значит, да ну его нафиг". Мы люди и мы склонны принимать комфортные для себя решения. Но, зачастую, этот комфорт ведёт к тому, что мы не принимаем решений, которые серьезно что-меняют. Мы остаёмся к привычном круге проблем и решений. Это очень понятно - в этом меньше риска и меньше трудозатрат.
Избежать "ловушки обыденности", просто, если сначала сопоставить масштабы влияния изменения и масштаб влияния проблем. Если тех, кому изменения принесут ценность, ощутимо больше тех, кому принесут проблемы, значит, можно рисовать диаграмму Исикавы и оценивать пути решения новых проблем.
Стоит помнить, что любое решение для кого-то будет хорошим, для кого-то плохим. "Оптимум" - это когда при прочих равных влияние недовольных на продукт минимально.
Получать результат за единицу времени
Одна из важнейших метрик продуктовых команд - полезность результата за единицу времени. Будь то спринт, релиз или квартальный цикл - у пользователей и стейкхолдеров должно быть стойкое ощущение полезности того результата работы, который вы им показываете. Для этого важно рассказывать не о функциях, а о самих пользователях. Что они смогут теперь делать или чего не делать. Не "у нас теперь есть трекер всех поступающих обращений", а "теперь ваши обращении не будут теряться, благодаря новому трекеру. Вы сможете в любой момент понять, в каком статусе и за кем закреплено обращение, а на само обращение обязательно будет получен ответ".
Как получать ценность в каждую единицу времени? Я использую три способа:
1. Ценность пользователя транслируется всей команде.
Это происходит, в первую очередь, на уровне языка. Даже программисты разговаривают терминами, понятными пользователям. Например, названия модулей, блоков или частей продукта совпадают с названиями ролей пользователей. Пусть даже код лежит в одном репозитории и изменяется под задачи пользователя настройками зон видимости.
2. Постановка задачи должна включать ответ на вопрос "чтобы что?"
Это и расширяет трансляцию ценностей, и даёт любому участнику команды правильный ценностный контекст. "Я, пользователь, хочу отчёт, чтобы показать руководителю динамику своей работы". "Я, пользователь, хочу отчёт, чтобы выстроить приоритеты для собственной деятельности". Почувствуйте разницу в контекстах.
3. Не надо делать слишком хорошо. Сделай нормально, но сделай.
В кейсе про трекер, конечно, главной ценностью было, в итоге, соблюдение SLA и снижение потерь от инцидентов. Но за один прыжок в неё не попасть, это игра в долгую. Плюс, надо не забывать, что в таком продукте основную ценность приносит не ИТ-программа, а процессы, которые выстраиваются вокруг автоматизированного workflow. На первой итерации мы действительно просто развернули трекер. У нас не было настроенных процессов, в форме была куча ненужных или непонятных полей, не всегда было понятно, кому маршрутизировать заявку. Но мы работали на одну метрику - 100% заявок должны получить ответ. Мы её выполнили, пользователи нам поверили. Поверили, что мы можем не только показывать красивые картинки. А мы получили опыт, который потом трансформировали в формальные процессы, базу знаний, инструкции для линий поддержки. Главное - делать.
Одна из важнейших метрик продуктовых команд - полезность результата за единицу времени. Будь то спринт, релиз или квартальный цикл - у пользователей и стейкхолдеров должно быть стойкое ощущение полезности того результата работы, который вы им показываете. Для этого важно рассказывать не о функциях, а о самих пользователях. Что они смогут теперь делать или чего не делать. Не "у нас теперь есть трекер всех поступающих обращений", а "теперь ваши обращении не будут теряться, благодаря новому трекеру. Вы сможете в любой момент понять, в каком статусе и за кем закреплено обращение, а на само обращение обязательно будет получен ответ".
Как получать ценность в каждую единицу времени? Я использую три способа:
1. Ценность пользователя транслируется всей команде.
Это происходит, в первую очередь, на уровне языка. Даже программисты разговаривают терминами, понятными пользователям. Например, названия модулей, блоков или частей продукта совпадают с названиями ролей пользователей. Пусть даже код лежит в одном репозитории и изменяется под задачи пользователя настройками зон видимости.
2. Постановка задачи должна включать ответ на вопрос "чтобы что?"
Это и расширяет трансляцию ценностей, и даёт любому участнику команды правильный ценностный контекст. "Я, пользователь, хочу отчёт, чтобы показать руководителю динамику своей работы". "Я, пользователь, хочу отчёт, чтобы выстроить приоритеты для собственной деятельности". Почувствуйте разницу в контекстах.
3. Не надо делать слишком хорошо. Сделай нормально, но сделай.
В кейсе про трекер, конечно, главной ценностью было, в итоге, соблюдение SLA и снижение потерь от инцидентов. Но за один прыжок в неё не попасть, это игра в долгую. Плюс, надо не забывать, что в таком продукте основную ценность приносит не ИТ-программа, а процессы, которые выстраиваются вокруг автоматизированного workflow. На первой итерации мы действительно просто развернули трекер. У нас не было настроенных процессов, в форме была куча ненужных или непонятных полей, не всегда было понятно, кому маршрутизировать заявку. Но мы работали на одну метрику - 100% заявок должны получить ответ. Мы её выполнили, пользователи нам поверили. Поверили, что мы можем не только показывать красивые картинки. А мы получили опыт, который потом трансформировали в формальные процессы, базу знаний, инструкции для линий поддержки. Главное - делать.
Всегда есть те, для кого проблема будет преимуществом
На одной из ретроспектив я с удивлением услышал благодарность продукт-менеджеру от одного из участников команды: "Спасибо за то, что ты знаешь, как работает наш продукт и отвечаешь на наши вопросы даже по ночам!". В моей парадигме управления продуктом такая ситуация - это мегафейл! Знания о продукте должны быть общими, их должно быть можно получить без обращения к менеджеру или коллеге по команде. Без этого у нас дикие риски остаться без знаний, низкая скорость выхода новых фич и высокие риски изменениями поломать что-то "переделав логику из лучших побуждений". Но команда с удовольствием приняла высказывание, менеджеру продукта такая похвала тоже пришлась в удовольствие. А самое главное, что это всё происходило в компании, которая показывает уверенный рост и занимает далеко не последнее место на своём рынке.
Мораль сей басни очень проста. Ценностная модель любой системы управления должна строиться от стратегических целей и решаемых задач. Не бывает хороших или плохих методов управления. Бывает лишь подходящие под ситуацию и неподходящие.
На одной из ретроспектив я с удивлением услышал благодарность продукт-менеджеру от одного из участников команды: "Спасибо за то, что ты знаешь, как работает наш продукт и отвечаешь на наши вопросы даже по ночам!". В моей парадигме управления продуктом такая ситуация - это мегафейл! Знания о продукте должны быть общими, их должно быть можно получить без обращения к менеджеру или коллеге по команде. Без этого у нас дикие риски остаться без знаний, низкая скорость выхода новых фич и высокие риски изменениями поломать что-то "переделав логику из лучших побуждений". Но команда с удовольствием приняла высказывание, менеджеру продукта такая похвала тоже пришлась в удовольствие. А самое главное, что это всё происходило в компании, которая показывает уверенный рост и занимает далеко не последнее место на своём рынке.
Мораль сей басни очень проста. Ценностная модель любой системы управления должна строиться от стратегических целей и решаемых задач. Не бывает хороших или плохих методов управления. Бывает лишь подходящие под ситуацию и неподходящие.
Ретроспектива - это анализ сделанного, а не ответ на вопрос "почему не сделали»
Очень часто происходит подмена понятий и на ретроспективе (или пост-анализе) начинают отвечать на вопрос "почему мы что-то не сделали". Вопрос важный, обсуждать и находить ответы на него нужно, но не нужно назвать это ретроспективой. Это проблема. Смешно слушать, когда диалог складывается примерно как: "Мы не смогли добежать до туалета, но мы всё равно молодцы, потому что можем отложить в баночку на анализы, авось, пригодится, коли не протухнет".
Ретроспектива нужна, когда есть зафиксированный результат. Достигнутая и подтвержденная ценность. И тогда важно понять, почему "нам было так сложно получить результат" или "почему нам пришлось потратить больше бюджета". Даже "почему мы не уложились в сроки" - хороший вопрос для разбора на ретре. Но в контексте полученного результата. Этот опыт даст возможность меньше ошибаться на следующем шаге, на следующей итерации.
Так же, на ретроспективе, важно не забывать и о позитивных рисках - "почему мы смогли сделать это быстрее, чем планировали" или "почему нам было это сделать проще, чем планировали". Без результата эти вопросы бесполезны, а значит и ценности у ретроспективы будет в несколько раз меньше.
Поэтому, если есть коммит - сжимаем зубы и получаем результат, проводим ретру, а потом уже даём более выполнимый коммит и работаем в спокойном режиме.
Очень часто происходит подмена понятий и на ретроспективе (или пост-анализе) начинают отвечать на вопрос "почему мы что-то не сделали". Вопрос важный, обсуждать и находить ответы на него нужно, но не нужно назвать это ретроспективой. Это проблема. Смешно слушать, когда диалог складывается примерно как: "Мы не смогли добежать до туалета, но мы всё равно молодцы, потому что можем отложить в баночку на анализы, авось, пригодится, коли не протухнет".
Ретроспектива нужна, когда есть зафиксированный результат. Достигнутая и подтвержденная ценность. И тогда важно понять, почему "нам было так сложно получить результат" или "почему нам пришлось потратить больше бюджета". Даже "почему мы не уложились в сроки" - хороший вопрос для разбора на ретре. Но в контексте полученного результата. Этот опыт даст возможность меньше ошибаться на следующем шаге, на следующей итерации.
Так же, на ретроспективе, важно не забывать и о позитивных рисках - "почему мы смогли сделать это быстрее, чем планировали" или "почему нам было это сделать проще, чем планировали". Без результата эти вопросы бесполезны, а значит и ценности у ретроспективы будет в несколько раз меньше.
Поэтому, если есть коммит - сжимаем зубы и получаем результат, проводим ретру, а потом уже даём более выполнимый коммит и работаем в спокойном режиме.
Техническая красота решения
Техническая красота решения имеет чёткие бизнесовые показатели - скорость, стоимость поддержки, удовлетворённость команды. Когда программист говорит: "А давайте всё это Г перепишем заново, а то оно ужасно написано", подумайте, какой показатель от этого изменения "выстрелит":
- уменьшится время на борьбу с багами при выходе новых версий?
- увеличится time2market?
- уменьшится число критичных (когда бизнес-пользователь не может выполнить свою работу даже обходным путём) инцидентов?
Если нет или не можете посчитать, значит, эта красота мнимая. С другой стороны, у разработки появляется чёткий водораздел - хочешь переписать, покажи прирост по этим показателям. Научись их считать. Ну, и сами не будьте сквалыгами - задачи, которые нужно сделать, чтобы начать собирать метрики, должны попадать в спринт, а не лежать вечно на задворках бэклога. Если хотим снизить баги при выходе новых версий - давайте время на юнит и автотетсты.
Отдельно хочу рассказать про удовлетворённость команды. Это важная составляющая для эффективной работы. Никому не нравится ковыряться в плохо структурированном коде, нарисованном фиг знает когда фиг знает кем. Если понимаете, что люди киснут, ищите новые задачи, которые можно попробовать решить новыми технологиями. Да, иногда это может быть "больно" в плане появления "зоопарка технологий", но тут приходится выбирать из двух зол - либо забить на эффективное и интенсивное развитие продукта, либо потерпеть переходный период к целевой технологии, но таки расти и развиваться функционально. Выбор в каждом случае свой.
Техническая красота решения имеет чёткие бизнесовые показатели - скорость, стоимость поддержки, удовлетворённость команды. Когда программист говорит: "А давайте всё это Г перепишем заново, а то оно ужасно написано", подумайте, какой показатель от этого изменения "выстрелит":
- уменьшится время на борьбу с багами при выходе новых версий?
- увеличится time2market?
- уменьшится число критичных (когда бизнес-пользователь не может выполнить свою работу даже обходным путём) инцидентов?
Если нет или не можете посчитать, значит, эта красота мнимая. С другой стороны, у разработки появляется чёткий водораздел - хочешь переписать, покажи прирост по этим показателям. Научись их считать. Ну, и сами не будьте сквалыгами - задачи, которые нужно сделать, чтобы начать собирать метрики, должны попадать в спринт, а не лежать вечно на задворках бэклога. Если хотим снизить баги при выходе новых версий - давайте время на юнит и автотетсты.
Отдельно хочу рассказать про удовлетворённость команды. Это важная составляющая для эффективной работы. Никому не нравится ковыряться в плохо структурированном коде, нарисованном фиг знает когда фиг знает кем. Если понимаете, что люди киснут, ищите новые задачи, которые можно попробовать решить новыми технологиями. Да, иногда это может быть "больно" в плане появления "зоопарка технологий", но тут приходится выбирать из двух зол - либо забить на эффективное и интенсивное развитие продукта, либо потерпеть переходный период к целевой технологии, но таки расти и развиваться функционально. Выбор в каждом случае свой.
Как говорить меньше, а делать больше
Обсуждать нужно и важно! Но часто аргументы двух точек зрения скатываются из области фактов в область гипотез, домыслов и частных точек зрения. Само по себе это неплохо, но съедается уйма времени на демагогию - это факты обсуждать быстро. Их интерпретациию дольше, но тоже недолго. А вот фантазии... Как только вы заметили, что диалог из фактов перешёл на гипотезы - остановитесь. И попробуйте обсудить, для какой из гипотез будет проще и быстрее собрать факты. Вот на ней и фокусируйтесь. На сборе фактов для её доказательства или опровержения. Сэкономите кучу времени!
Обсуждать нужно и важно! Но часто аргументы двух точек зрения скатываются из области фактов в область гипотез, домыслов и частных точек зрения. Само по себе это неплохо, но съедается уйма времени на демагогию - это факты обсуждать быстро. Их интерпретациию дольше, но тоже недолго. А вот фантазии... Как только вы заметили, что диалог из фактов перешёл на гипотезы - остановитесь. И попробуйте обсудить, для какой из гипотез будет проще и быстрее собрать факты. Вот на ней и фокусируйтесь. На сборе фактов для её доказательства или опровержения. Сэкономите кучу времени!
Мифы и легенды утреннего стендапа
Утренний стендап - это инструмент, в первую очередь, менеджера. Именно здесь менеджер продукта понимает, работает ли его команда по процессу, или внутри царит "творческий беспорядок". Процесс необходим для повторяемости результата. Для продукта это даже более важно, чем для проекта. Ежедневный стендап - это инструмент внутри операционного цикла, из котрого сам менеджер должен быть исключён. Задача менеджера помогать команде поддерживать и развивать процессы.
К стендапу нужно готовиться. Как участникам команды разработки, так и менеджеру. Первым - привести в порядок карточки в трекере, оценить риски и сложности текущих задач, подумать, с кем нужно провзаимодействовать, чтобы задача успешно решилась. Менеджер должен понять, какие задачи лежат на критическом пути спринта и задать вопросы по ним.
Если такая подготовка происходит, то стендап проходит действительно быстро - каждый по очереди называет номер и суть задачи, что было сделано за день, и что планируется сделать за сегодня. Кто и по какому вопросу нужен. Если на вопрос "что сделано вчера" или "чем планируешь заниматься сегодня" человек начинает долго думать и пространно рассуждать - менеджеру стоит задуматься о процессах внутри команды.
Утренний стендап - это инструмент, в первую очередь, менеджера. Именно здесь менеджер продукта понимает, работает ли его команда по процессу, или внутри царит "творческий беспорядок". Процесс необходим для повторяемости результата. Для продукта это даже более важно, чем для проекта. Ежедневный стендап - это инструмент внутри операционного цикла, из котрого сам менеджер должен быть исключён. Задача менеджера помогать команде поддерживать и развивать процессы.
К стендапу нужно готовиться. Как участникам команды разработки, так и менеджеру. Первым - привести в порядок карточки в трекере, оценить риски и сложности текущих задач, подумать, с кем нужно провзаимодействовать, чтобы задача успешно решилась. Менеджер должен понять, какие задачи лежат на критическом пути спринта и задать вопросы по ним.
Если такая подготовка происходит, то стендап проходит действительно быстро - каждый по очереди называет номер и суть задачи, что было сделано за день, и что планируется сделать за сегодня. Кто и по какому вопросу нужен. Если на вопрос "что сделано вчера" или "чем планируешь заниматься сегодня" человек начинает долго думать и пространно рассуждать - менеджеру стоит задуматься о процессах внутри команды.
Весь таймменеджмент умещается в одну фразу: "Понять, что можно просрать, а что нельзя, и сосредоточиться на втором". Любой другой выбор - лишь иллюзия, такая же, как и у ребёнка, которого спрашивают: "Какую кашу ты будешь: манную или овсяную?". Всегда есть внешние обстоятельства, которые диктуют нам контекст, в котором мы делаем тот самый, единственный выбор. Работаешь в найме - контекст задаёт руководитель. Ты глава собственной фирмы - контекст зависит от договоров с клиентами и дат выплат ЗП сотрудникам. Отличие взрослого от ребёнка в том, что взрослый может сам выбирать свой контекст - например, работать по найму или открыть собственный бизнес. Но это выбор не имеет к таймменеджменту никакого отношения.
Собственно, прочитав мой пост, вы теперь можете не читать больше ни одной книги про таймменеджмент, ибо, отжав воду, вы получите ровно ту заветную фразу :)
Собственно, прочитав мой пост, вы теперь можете не читать больше ни одной книги про таймменеджмент, ибо, отжав воду, вы получите ровно ту заветную фразу :)
Врач - лучший учитель по CustDev
Хотите прокачать навык по сбору проблем и подтверждению гипотез с пользой для здоровья? Сходите на приём к врачу и запишите разговор с ним. Ведь врач на приёме занимается именно проблемным интервью:
— Что беспокоит?
— Когда началось?
— Колет или тянет?
— Какие лекарства уже принимали?
Каждый вопрос - это вопрос о вас, о вашей жизни и, одновременно, проверка гипотезы:
— Больнее, когда нажимаю или когда отпускаю?
— Когда надавливаете
— Значит, вероятность аппендицита низкая.
Ровно этим занимается менеджер продукта. И основная ошибка - задавать вопросы, подтверждающие гипотезу, которую менеджеру хочется подтвердить:
— Вы бы купили за миллион эту потрясающую машинку для завязывания шнурков?
— Конечно, какой разговор! Как только у вас появится машинка - первым делом ко мне! (возможно, у меня уже появится к этому времени лишний миллион на открытие музея самых идиотских изобретений человечества)
Готовясь к интервью, задайте себе мысленно вопрос: "А не похож ли я на врача, которому нравится лечить аппендицит и он всем средствами пытается обнаружить его у пациента?". И составляйте вопросы так, чтобы не быть таким врачом:
— Какую обувь предпочитаете?
— Спортивную, в основном - кеды, кроссы
— Вы завязываете шнурки на них сидя или стоя?
— Я вообще не завязываю, так как купил эластичные и просто надеваю
— А бегом вы занимаетесь?
— Конечно! Два-три раза в неделю бегаю.
— И на спортивных кроссах тоже используете эластичные шнурки?
— Нет, там, конечно, обычные, чтобы лучше держали ногу.
— Доверили бы машинке завязать шнурки на спортивных кроссах, чтобы не наклоняться к ним?
— Нет, мне важно чувствовать силу затяжки. И, кстати, я не наклоняюсь, я всегда завязываю сидя, поставив ногу на пятку, чтобы правильно расположить кроссовок на ноге.
— Круто, не знал! А зимой тоже бегаете?
— Зимой мне нравятся коньки. Кстати, там как раз такой гемор со шнуровкой и разшнуровкой - каждый виточек затяни, потом растяни...
Ну, а если пока не получается кастдевить - не трать деньги на курсы, просто сходи к врачу :)
Хотите прокачать навык по сбору проблем и подтверждению гипотез с пользой для здоровья? Сходите на приём к врачу и запишите разговор с ним. Ведь врач на приёме занимается именно проблемным интервью:
— Что беспокоит?
— Когда началось?
— Колет или тянет?
— Какие лекарства уже принимали?
Каждый вопрос - это вопрос о вас, о вашей жизни и, одновременно, проверка гипотезы:
— Больнее, когда нажимаю или когда отпускаю?
— Когда надавливаете
— Значит, вероятность аппендицита низкая.
Ровно этим занимается менеджер продукта. И основная ошибка - задавать вопросы, подтверждающие гипотезу, которую менеджеру хочется подтвердить:
— Вы бы купили за миллион эту потрясающую машинку для завязывания шнурков?
— Конечно, какой разговор! Как только у вас появится машинка - первым делом ко мне! (возможно, у меня уже появится к этому времени лишний миллион на открытие музея самых идиотских изобретений человечества)
Готовясь к интервью, задайте себе мысленно вопрос: "А не похож ли я на врача, которому нравится лечить аппендицит и он всем средствами пытается обнаружить его у пациента?". И составляйте вопросы так, чтобы не быть таким врачом:
— Какую обувь предпочитаете?
— Спортивную, в основном - кеды, кроссы
— Вы завязываете шнурки на них сидя или стоя?
— Я вообще не завязываю, так как купил эластичные и просто надеваю
— А бегом вы занимаетесь?
— Конечно! Два-три раза в неделю бегаю.
— И на спортивных кроссах тоже используете эластичные шнурки?
— Нет, там, конечно, обычные, чтобы лучше держали ногу.
— Доверили бы машинке завязать шнурки на спортивных кроссах, чтобы не наклоняться к ним?
— Нет, мне важно чувствовать силу затяжки. И, кстати, я не наклоняюсь, я всегда завязываю сидя, поставив ногу на пятку, чтобы правильно расположить кроссовок на ноге.
— Круто, не знал! А зимой тоже бегаете?
— Зимой мне нравятся коньки. Кстати, там как раз такой гемор со шнуровкой и разшнуровкой - каждый виточек затяни, потом растяни...
Ну, а если пока не получается кастдевить - не трать деньги на курсы, просто сходи к врачу :)
ChatGPT - не инструмент, а сотрудник
Очень многие уже попробовали ChatGPT для своих задач. И очень много негатива, связанного именно с тем, чем ChatGPT является - генеративной (то есть, "выдумывательной") сетью. У меня "картинка схлопнулась" в отношении к ChatGPT, как только я стал относиться к нему не как к инструменту, а как к еще одному сотруднику - Чату Виленовичу Аитову:
- как и любому сотруднику, Чату Виленовичу нужно конкретно формулировать задачу (а правильная постановка задачи зачастую половина дела);
- как и любой другой сотрудник, Чат Виленович выдаёт суждения и результаты с "персональным когнитивным искажением", поэтому нужна хотя бы минимальная проверка результата;
- как и любой другой сотрудник, Чат Виленович требует обучения именно на ваших данных
Если вы привыкли именно к инструментам - калькулятор всегда выдает одинаковый результат - то добро пожаловать в реальный мир, где бухгалтер с калькулятором легко выдает абсолютно разные ответы на одних и тех же данных в одном и том же отчёте, стоит попросить "еще раз проверить".
Просо расширяйте свои возможности, наняв по одному почти бесплатному сотруднику в каждый отдел, но не ждите идеальной работы. Всё так же, как и с реальными людьми! :)
Очень многие уже попробовали ChatGPT для своих задач. И очень много негатива, связанного именно с тем, чем ChatGPT является - генеративной (то есть, "выдумывательной") сетью. У меня "картинка схлопнулась" в отношении к ChatGPT, как только я стал относиться к нему не как к инструменту, а как к еще одному сотруднику - Чату Виленовичу Аитову:
- как и любому сотруднику, Чату Виленовичу нужно конкретно формулировать задачу (а правильная постановка задачи зачастую половина дела);
- как и любой другой сотрудник, Чат Виленович выдаёт суждения и результаты с "персональным когнитивным искажением", поэтому нужна хотя бы минимальная проверка результата;
- как и любой другой сотрудник, Чат Виленович требует обучения именно на ваших данных
Если вы привыкли именно к инструментам - калькулятор всегда выдает одинаковый результат - то добро пожаловать в реальный мир, где бухгалтер с калькулятором легко выдает абсолютно разные ответы на одних и тех же данных в одном и том же отчёте, стоит попросить "еще раз проверить".
Просо расширяйте свои возможности, наняв по одному почти бесплатному сотруднику в каждый отдел, но не ждите идеальной работы. Всё так же, как и с реальными людьми! :)
Как понять, что ты чему-то научился?
Сейчас, по-моему, есть курсы даже про то, как лениться. Что уж говорить о профессиональных курсах и бизнес-литературе. Да и обычная художественная литература нас учит психологии, как минимум. Но как понять, что ты чему-то научился, пройдя курс или прочитав книгу?
Сначала всё просто. Если твои взгляды поменялись, точка зрения изменилась - значит, ты научился. Перестал думать, что земля плоская? Узнал, что параллельные прямые могут пересекаться? Перестал верить правым и стал верить левым - всё это примеры роста.
Со временем ты накапливаешь достаточно обширный арсенал знаний. Если ты эти знания применяешь, то у тебя параллельно накапливается опыт. В какой-то момент ты понимаешь, что не готов отказываться от какого-то знания или точки зрения, так как есть опыт положительного эффекта от каждой из них. Или ты понимаешь, что у каждой из точек зрения недостаточно фактической докащательной базы.
Теперь мерилом того, научился ли ты чему-то будет служить понимание границ и контекста каждой точки зрения, технологии или знания. Agile и водопад - если ты понял, в каких ситуациях и условиях какую технологию применять - ты научился. Смог найти в споре двух сторон условия, при которых каждый из оппонентов будет прав - ты научился.
Прочитал этот пост и сформировал свою точку зрения на этот вопрос - отлично, значит, ты научился! :)
Сейчас, по-моему, есть курсы даже про то, как лениться. Что уж говорить о профессиональных курсах и бизнес-литературе. Да и обычная художественная литература нас учит психологии, как минимум. Но как понять, что ты чему-то научился, пройдя курс или прочитав книгу?
Сначала всё просто. Если твои взгляды поменялись, точка зрения изменилась - значит, ты научился. Перестал думать, что земля плоская? Узнал, что параллельные прямые могут пересекаться? Перестал верить правым и стал верить левым - всё это примеры роста.
Со временем ты накапливаешь достаточно обширный арсенал знаний. Если ты эти знания применяешь, то у тебя параллельно накапливается опыт. В какой-то момент ты понимаешь, что не готов отказываться от какого-то знания или точки зрения, так как есть опыт положительного эффекта от каждой из них. Или ты понимаешь, что у каждой из точек зрения недостаточно фактической докащательной базы.
Теперь мерилом того, научился ли ты чему-то будет служить понимание границ и контекста каждой точки зрения, технологии или знания. Agile и водопад - если ты понял, в каких ситуациях и условиях какую технологию применять - ты научился. Смог найти в споре двух сторон условия, при которых каждый из оппонентов будет прав - ты научился.
Прочитал этот пост и сформировал свою точку зрения на этот вопрос - отлично, значит, ты научился! :)
Подал заявку на выступление на ProductCamp! Фишка конференции в том, что в сетку попадают доклады, за которое проголосовало больше всего людей. Буду признателен, если поддержите голосом мой доклад. Если, конечно, считаете тему интересной https://docs.google.com/forms/d/e/1FAIpQLSd4kjAx07fAbV7DBcow_HMC-KxcLnyl7nXPDOfe54Nwpyd-lg/viewform
На 10-й странице :)
На 10-й странице :)
Классикой управления является задавать три вопроса:
- почему это произошло?
- что мы сделали не так?
- что мы поменяем, чтобы это не происходило?
Представьте, вы вышли из дома. Вдруг какой-то особо меткий,но и особо безмозглый голубь ставит сочную отметку на вашем пиджаке. Конечно, можно задать себе три классических вопроса и придумать массу того, что мы поменяем, чтобы больше такого не происходило. Но стоит ли?
Прежде, чем что-то менять, задайте себе три вопроса:
- Как часто возникает подобное событие?
- Можем ли выразить влияние в каких-то измеримых величинах?
- Какие новые проблемы породит реализация каждого предложенного решения?
Ответы на эти вопросы помогут избежать лишней суеты и менять только то, что стоит изменения. Помогут избежать ловушки, когда постоянно что-то делаешь, всё время занят, а выхлопа в результате 0.
- почему это произошло?
- что мы сделали не так?
- что мы поменяем, чтобы это не происходило?
Представьте, вы вышли из дома. Вдруг какой-то особо меткий,но и особо безмозглый голубь ставит сочную отметку на вашем пиджаке. Конечно, можно задать себе три классических вопроса и придумать массу того, что мы поменяем, чтобы больше такого не происходило. Но стоит ли?
Прежде, чем что-то менять, задайте себе три вопроса:
- Как часто возникает подобное событие?
- Можем ли выразить влияние в каких-то измеримых величинах?
- Какие новые проблемы породит реализация каждого предложенного решения?
Ответы на эти вопросы помогут избежать лишней суеты и менять только то, что стоит изменения. Помогут избежать ловушки, когда постоянно что-то делаешь, всё время занят, а выхлопа в результате 0.