95. Не стоит увлекаться процессами
Вот вы маленький софтверный стартап с командой человек на 8. У вас есть рынок, идея и что-то разрабатывается. Возможно вас посещают мысли об эффективных процессах. Может попробовать Scrum? Говорят неплохо работает. Или Kanban? Он модный и звучит хорошо. Или DevOps? Такое популярное слово не может быть плохим и бесполезным.
Ответ на все эти вопросы прост:
Забейте. Я серьезно. Вам не нужен Scrum, Kanban или любой другой формальный процесс. На самом деле вам нужно всего три вещи:
- Видение продукта → Список фич с кратким описанием и приоритетами.
- Визуализация кто над какой фичей сейчас работает и когда примерно закончит.
- Continuous Integration (и чуть позже Continuous Deployment)
Больше можно ничего не иметь. Вам, скорее всего, не нужны дейли митинги, итерации, регулярные ретроспективы, эстимейты, регулярные сессии планирования работы, WIP Limits, тестировщики, юзер стори, правильные форматы описания фич и прочая муть. Не нужно отвлекать программистов от решения важных задач. Они должны понимать, что делают и решать проблемы как можно быстрее.
Совершенно бессмысленно долго обсуждать длительность задачи, если она всё равно обязана быть сделана для успеха продукта. Бессмысленно проводить дейли митинги, если команда решает все возникающие проблемы ad hoc в течение рабочего дня. Формальные итерации не дают никаких преимуществ в продуктивности, но зато заставляют тратить время на втискивание работы в себя и слишком мелкую декомпозицию с участием всей команды. Отсутствие процессов делает ретроспективы ненужными, чего обсуждать процесс, если его нет? Лимиты на количество задач тривиальны. Один разработчик — одна задача в процессе (ну иногда может быть две).
Для команды гораздо более важны вещи, которые слабо решаются процессами:
- Взаимопомощь
- Желание устраивать спонтанные обсуждения нужных вопросов
- Отвага поднимать важные проблемы (вплоть до “а не хуйню ли мы тут все делаем?”)
- Пёр (модное слово от Сергея Карелова)
- Увлеченность общим делом
И в хорошей команде отсутствует:
- Соревнование между отдельными программистами
- КPI
- Распиздяйство
- Автоматизм выполнения задач
- Микро-менеджмент
У маленького софтверного стартапа на первых порах есть единственная задача — выпустить версию продукта на рынок и получить от него обратную связь. Время должно тратиться только на две вещи:
- Видение (анализ рынка, разговоры с клиентами, продумывание решений)
- Разработку (дизайн и программирование)
Процессами можно увлекаться, когда есть быстрый рост и наблюдаются драматические потери эффективности. Вот тогда можно начинать думать о том, как передавать информацию между 50 разработчиками, как их объединять единой целью и как что-то выпускать за неделю, а не за месяц. Но до тех прекрасных пор — забейте на процессы.
P.S. Самые наблюдательные найдут в тексте акростих (ну, почти).