Недавно я провёл опрос о том, как опрашиваемые и их команды разрабатывают ПО. Ниже представлена сводка результатов опроса.
В настоящее время я занимаюсь созданием Shaped: легковесного планировщика и трекера разработки продуктов для стартапов и небольших команд. Мне хотелось узнать больше о том, как современные команды подходят к разработке ПО и с какими сложностями они сталкиваются.
Опрос прошло чуть менее ста человек.
Большинство работает в крупных компаниях из более чем ста сотрудников (это не мой целевой рынок, но на нём всё равно есть интересные данные).
Заодно я выяснил, где работают команды, и с удивлением узнал, что большинство по-прежнему работает удалённо или гибридно (совмещает офис с удалёнкой). Я предполагал, что крупные компании хотя бы начали возврат обратно в офис.
К сожалению, я не догадался задать вопрос о местонахождении компании. Было бы интересно узнать, существует ли корреляция между этим и удалённой/гибридной/офисной работой.
Как бы то ни было, теперь у нас есть представление о том, как выглядят эти команды. Перейдём к самому важному в опросе: как команды планируют и разрабатывают ПО.
При планировании работы команд разработчиков большинство компаний использует дорожные карты фич (feature roadmap). Так поступают не только большие компании — заметно, что такой подход достаточно ровно распределён по компаниям всех размеров.
Feature roadmap — самый популярный подход. Сегодня кто-то может считать его немного устаревшим, однако руководители и начальство с трудом отказываются от него, потому что он даёт им ощущение понятности и контроля. Самый большой недостаток feature roadmap в том, что они предполагают, что планируемая фича действительно нужна в продукте. Они заставляют команды создавать решения, которые не будут работать, приводя таким образом к пустой трате времени.
На четвёртом месте находится theme/outcome-based roadmap. Эта техника планирования схожа с feature roadmap, однако вместо планирования «разрабатываемых фич» в ней бизнес планирует «результаты, которых нужно достичь». Это незначительное изменение приводит к тому, что команды стремятся не к реализации конкретных фич, а к достижению определённых результатов. И ответственность переходит к командам, изучающим и создающим нужные решения.
Концепция дорожных карт результатов похожа на OKR, в которых используется та же фундаментальная идея, но более структурированно.
Для стартапов я обычно рекомендую в качестве хорошего фреймворка планирования Now/Next/Later. Стартапы обычно часто меняют направление развития, потому что они узнают новое и исследуют новые возможности. Поэтому ограничивающее планирование того, что происходит сейчас (Now), что они будут делать дальше (Next) и что можно будет делать позже (Later) — полезный способ управления ограниченными ресурсами.
Большинство компаний выполняют планирование поквартально. Это разумный временной промежуток, дающий командам возможность браться за крупные задачи и обеспечивать существенные результаты.
Меня немного беспокоит то, что одна компания планирует вперёд на пять лет!
Удовлетворённость своей методикой планирования достаточно равномерно распределена по компаниям различных размеров. Однако похоже, что компании с 2-10 сотрудниками имеют преимущество. На этом этапе жизни компании планирование обычно бывает достаточно простой задачей.
Между удовлетворённостью и методикой планирования или дальностью планирования особых корреляций нет.
В сфере используемых процессов разработки с большим отрывом выигрывает Scrum.
Следующим идёт пункт Mixture (смесь) — команды используют смесь разных техник под собственные нужды.
Любопытно, что третий по популярности процесс — полное отсутствие процесса. Не понимаю, как это получается у больших компаний!
Shape Up — это относительно новая методология, созданная командой разработчиков Basecamp. Я в восторге этого процесса и считаю, что он очень хорошо подходит для команд стартапов.
Здесь нет особых сюрпризов, большинство команд работает циклами по две недели.
Jira — это ПО, которое все любят и ненавидят, но всё равно используют! На четвёртом месте Trello — можно сказать, что Atlassian отхватила приличную долю рынка.
Гораздо удивительнее то, что многие люди используют электронные таблицы (spreadsheet). Впрочем, стоит заметить, что в этом вопросе можно было выбрать несколько вариантов ответа. То есть это не значит, что некоторые команды используют электронные таблицы в качестве единственного инструмента для планирования и трекинга.
Зачем я это делал
В настоящее время я занимаюсь созданием Shaped: легковесного планировщика и трекера разработки продуктов для стартапов и небольших команд. Мне хотелось узнать больше о том, как современные команды подходят к разработке ПО и с какими сложностями они сталкиваются.
Результаты
Кто отвечал на вопросы?
Опрос прошло чуть менее ста человек.
Большинство работает в крупных компаниях из более чем ста сотрудников (это не мой целевой рынок, но на нём всё равно есть интересные данные).
Заодно я выяснил, где работают команды, и с удивлением узнал, что большинство по-прежнему работает удалённо или гибридно (совмещает офис с удалёнкой). Я предполагал, что крупные компании хотя бы начали возврат обратно в офис.
К сожалению, я не догадался задать вопрос о местонахождении компании. Было бы интересно узнать, существует ли корреляция между этим и удалённой/гибридной/офисной работой.
Как бы то ни было, теперь у нас есть представление о том, как выглядят эти команды. Перейдём к самому важному в опросе: как команды планируют и разрабатывают ПО.
Процесс планирования разработки
При планировании работы команд разработчиков большинство компаний использует дорожные карты фич (feature roadmap). Так поступают не только большие компании — заметно, что такой подход достаточно ровно распределён по компаниям всех размеров.
Feature roadmap — самый популярный подход. Сегодня кто-то может считать его немного устаревшим, однако руководители и начальство с трудом отказываются от него, потому что он даёт им ощущение понятности и контроля. Самый большой недостаток feature roadmap в том, что они предполагают, что планируемая фича действительно нужна в продукте. Они заставляют команды создавать решения, которые не будут работать, приводя таким образом к пустой трате времени.
На четвёртом месте находится theme/outcome-based roadmap. Эта техника планирования схожа с feature roadmap, однако вместо планирования «разрабатываемых фич» в ней бизнес планирует «результаты, которых нужно достичь». Это незначительное изменение приводит к тому, что команды стремятся не к реализации конкретных фич, а к достижению определённых результатов. И ответственность переходит к командам, изучающим и создающим нужные решения.
Концепция дорожных карт результатов похожа на OKR, в которых используется та же фундаментальная идея, но более структурированно.
Для стартапов я обычно рекомендую в качестве хорошего фреймворка планирования Now/Next/Later. Стартапы обычно часто меняют направление развития, потому что они узнают новое и исследуют новые возможности. Поэтому ограничивающее планирование того, что происходит сейчас (Now), что они будут делать дальше (Next) и что можно будет делать позже (Later) — полезный способ управления ограниченными ресурсами.
Большинство компаний выполняют планирование поквартально. Это разумный временной промежуток, дающий командам возможность браться за крупные задачи и обеспечивать существенные результаты.
Меня немного беспокоит то, что одна компания планирует вперёд на пять лет!
Удовлетворённость своей методикой планирования достаточно равномерно распределена по компаниям различных размеров. Однако похоже, что компании с 2-10 сотрудниками имеют преимущество. На этом этапе жизни компании планирование обычно бывает достаточно простой задачей.
Между удовлетворённостью и методикой планирования или дальностью планирования особых корреляций нет.
Процесс разработки ПО
В сфере используемых процессов разработки с большим отрывом выигрывает Scrum.
Следующим идёт пункт Mixture (смесь) — команды используют смесь разных техник под собственные нужды.
Любопытно, что третий по популярности процесс — полное отсутствие процесса. Не понимаю, как это получается у больших компаний!
Shape Up — это относительно новая методология, созданная командой разработчиков Basecamp. Я в восторге этого процесса и считаю, что он очень хорошо подходит для команд стартапов.
Здесь нет особых сюрпризов, большинство команд работает циклами по две недели.
Инструменты трекинга разработки
Jira — это ПО, которое все любят и ненавидят, но всё равно используют! На четвёртом месте Trello — можно сказать, что Atlassian отхватила приличную долю рынка.
Гораздо удивительнее то, что многие люди используют электронные таблицы (spreadsheet). Впрочем, стоит заметить, что в этом вопросе можно было выбрать несколько вариантов ответа. То есть это не значит, что некоторые команды используют электронные таблицы в качестве единственного инструмента для планирования и трекинга.