А я вот наоборот признателен за такое общее описание функциональности. Как раз начал изучать подобные решения, чтобы сделать для себя краткое сравнение, а тут в готовом виде подъехал материал!
Сравнение APEX с другими аналогичными решениями было бы тоже интересно почитать :)
1. Вот прямо в этом комментарии и противопоставляете менеджеров разработчикам.
2. Менеджмент в вашей модели мира — это какие-то полубоги с долей в прибыли, а на самом деле 99% менеджеров точно такие же наемные сотрудники, тем более в больших компаниях.
3. Просто представьте себе ситуацию, когда вы и ваш менеджер разработки делаете все, чтобы помочь друг другу в работе: менеджер добивается у своего руководства обязательного бюджета на рефакторинг, хорошего железа, пары больших мониторов и дивана в офис, чтобы не спать после обеда лицом в клавиатуре. А вы помогаете менеджеру в его работе: помогаете ему оценить сроки, не подводите его без необходимости, сразу сообщаете о проблемах, конструктивно помогаете ему увидеть ошибки. Приятно было бы работать в таких условиях?
Просто чтобы донести основную мысль, иногда приходится утрировать. Иначе, если доносить главную мысль со всеми должными уточнениями и оговорками, она ускользает от внимания в потоке слов :)
Вообще, с хорошей командой и торопиться можно не спеша, без перегибов, и технический долг оставлять минимальный. Но расслабленного отношения к работе создания нового продукта не прощает.
Я понял. У вас был травмирующий опыт, ситуация, когда недобросовестное руководство манипулировало разработчиками через их чрезмерно развитое чувство ответственности.
И теперь вы противопоставляете себя коллегам и руководству, вместо того, чтобы считать всех одной командой единомышленников, где все друг друга поддерживают.
Даже не знаю, как теперь помочь вам поверить, что это не норма, и так бывает далеко не всегда :(
То есть вы, по сути, предоставили руководству исходные данные для оценки сроков, но брать ответственность за сроки на себя не готовы по каким-то причинам? Правильно?
Здоровая мотивация начинается там, где вы (в составе команды), а не менеджмент, управляете своим процессом разработки. И сами назначаете сроки.
Менеджмент приходит к вам с набором feature requests и спрашивает, что и когда вы можете сделать.
Вы все декомпозируете, оцениваете, и предлагаете менеджменту несколько вариантов, как можно раскидать его запросы по порядку реализации и вы вместе исходя из приоритетов формируете план разработки.
И это ваш план, ваш процесс, ваши оценки и только от вас зависит результат.
И уж где-где, а в Контуре точно возможен такой процесс)
Есть мнение, что без спешки разрабатывается только ПО, которое заведомо никому не нужно.
Даже если у вас нет наступающих на пятки конкурентов, кучи пользователей с запросами, маркетологов, которые требуют фич для новых классов клиентов, вас все равно подгоняет как минимум ограничения бюджета/контракта/объема инвестиций/терпения внешнего или внутреннего инвестора.
А умение делать быстро, но без ущерба качеству — это и есть искусство разработки ПО, индивидуальное и командное.
Вы тоже так считаете. Не зря же вы писали, что работа стремится занять все отведенное под нее время. А представьте себе, что время вообще не ограничено. Немедленно случится паралич перфекционизма, или решение задачи в общем виде, или написание целого фреймворка — под функцию, которой клиенты, может, вообще не будут никогда пользоваться.
Без сроков нельзя брать ответственность?
Можно. Но бизнесу/владельцу продукта нужны сроки. Если их спускают сверху, команда переходит в режим прикрытия задницы и теряет продуктивность. А дать собственную обоснованную оценку команда может, только оценивая свои задачи. А когда команда такую оценку дает, она получает серьезную мотивацию в нее уложиться. Тут хотите — поверьте моему опыту, не хотите — попробуйте сами)
— Ты когда-нибудь слышал о смягчающих обстоятельствах?
— Все, что только можно.
Смотрите.
Я бы хотел, чтобы разработчики (и в целом команды) Контура создавали новые крутые проекты. Именно за этим идут в разработку ПО. Это вводная.
Практика доказывает, что крутые проекты могут делать только крайне мотивированные команды голодных разработчиков с горящими глазами, которые безостановочно изучают клиента, пробуют новые гипотезы и не останавливаются, пока не нащупают облик реального продукта. Это идеальная команда по Бруксу и Листеру.
Если в ходе этого поиска сроки решения задач не ограничивать, команда теряет фокус и начинает делать всякую ненужную побочную фигню, и проект заболачивается, а потом и умирает.
Но если команду и ее разработчиков начать подгонять сверху и спускать какие-то сроки, это создаст у разработчиков понимание, что конечный результат от них не зависит, и вместо пылающих глаз мы получим горящие пуканы и, опять же, торможение и гибель проекта. Это один из идеальных сценариев «травли команд» по Бруксу и Листеру. Именно в таких условиях разработчики начинают раздувать сроки и бездельничать, сделав переоцененную задачу — им нужно прикрыть задницу, а не построить вместе с командой крутой продукт.
Тонкая грань максимальной эффективности команды — это режим, в котором команда полностью вовлечена и все участники чувствуют, что результат зависит только от них, берут на себя личную ответственность за результат. При этом темп поддерживается максимально высокий, сроки поставки фич и проверки гипотез остаются управляемыми. Нужно, чтобы команда оценивала сроки работы над задачами, чтобы она по-честному могла взять на себя ответственность за обоснованные сроки поставки.
Таким образом, автор, по сути, призывает к тому, чтобы команды Контура работали расслабленно, без огонька. А значит и без шансов сделать что-то действительно крутое.
Спринт обычный, фиксированный. Сроки оцениваются не для спринта, а для фич, которые бывают разными и могут делаться в несколько спринтов или просто уезжать вперед из-за нехватки времени в текущем или следующем.
То, что команда сама выполняет функции менеджера — дает огромный буст к мотивации и чувство драйва. То есть, счастливы и заказчики, и команда. Именно это невозможно при подходе, описанном автором оригинального поста.
Нет. Набрали задач в итерацию, оставив оговоренный запас для непредвиденных задач (багов) и на случай ошибок в оценках. И уже тогда огласили какие-то сроки.
Оценка каждой задачи — необходимый источник данных, чтобы назвать конечный срок, но никто в здравом уме не суммирует их механически. И команда никогда не подпишется под такой оценкой. И автор поста тоже пишет, что так делают только неадекватные менеджеры.
Сравнение APEX с другими аналогичными решениями было бы тоже интересно почитать :)
2. Менеджмент в вашей модели мира — это какие-то полубоги с долей в прибыли, а на самом деле 99% менеджеров точно такие же наемные сотрудники, тем более в больших компаниях.
3. Просто представьте себе ситуацию, когда вы и ваш менеджер разработки делаете все, чтобы помочь друг другу в работе: менеджер добивается у своего руководства обязательного бюджета на рефакторинг, хорошего железа, пары больших мониторов и дивана в офис, чтобы не спать после обеда лицом в клавиатуре. А вы помогаете менеджеру в его работе: помогаете ему оценить сроки, не подводите его без необходимости, сразу сообщаете о проблемах, конструктивно помогаете ему увидеть ошибки. Приятно было бы работать в таких условиях?
Просто чтобы донести основную мысль, иногда приходится утрировать. Иначе, если доносить главную мысль со всеми должными уточнениями и оговорками, она ускользает от внимания в потоке слов :)
Вообще, с хорошей командой и торопиться можно не спеша, без перегибов, и технический долг оставлять минимальный. Но расслабленного отношения к работе создания нового продукта не прощает.
Если такие ситуации — исключение, то на конечный результат они не влияют.
Если кто-то конкретный регулярно срывает сроки задач, которые были оценены коллегиально, то эту ситуацию разбирают отдельно.
И теперь вы противопоставляете себя коллегам и руководству, вместо того, чтобы считать всех одной командой единомышленников, где все друг друга поддерживают.
Даже не знаю, как теперь помочь вам поверить, что это не норма, и так бывает далеко не всегда :(
Менеджмент приходит к вам с набором feature requests и спрашивает, что и когда вы можете сделать.
Вы все декомпозируете, оцениваете, и предлагаете менеджменту несколько вариантов, как можно раскидать его запросы по порядку реализации и вы вместе исходя из приоритетов формируете план разработки.
И это ваш план, ваш процесс, ваши оценки и только от вас зависит результат.
И уж где-где, а в Контуре точно возможен такой процесс)
Даже если у вас нет наступающих на пятки конкурентов, кучи пользователей с запросами, маркетологов, которые требуют фич для новых классов клиентов, вас все равно подгоняет как минимум ограничения бюджета/контракта/объема инвестиций/терпения внешнего или внутреннего инвестора.
А умение делать быстро, но без ущерба качеству — это и есть искусство разработки ПО, индивидуальное и командное.
Вы тоже так считаете. Не зря же вы писали, что работа стремится занять все отведенное под нее время. А представьте себе, что время вообще не ограничено. Немедленно случится паралич перфекционизма, или решение задачи в общем виде, или написание целого фреймворка — под функцию, которой клиенты, может, вообще не будут никогда пользоваться.
Можно. Но бизнесу/владельцу продукта нужны сроки. Если их спускают сверху, команда переходит в режим прикрытия задницы и теряет продуктивность. А дать собственную обоснованную оценку команда может, только оценивая свои задачи. А когда команда такую оценку дает, она получает серьезную мотивацию в нее уложиться. Тут хотите — поверьте моему опыту, не хотите — попробуйте сами)
Смотрите.
Я бы хотел, чтобы разработчики (и в целом команды) Контура создавали новые крутые проекты. Именно за этим идут в разработку ПО. Это вводная.
Практика доказывает, что крутые проекты могут делать только крайне мотивированные команды голодных разработчиков с горящими глазами, которые безостановочно изучают клиента, пробуют новые гипотезы и не останавливаются, пока не нащупают облик реального продукта. Это идеальная команда по Бруксу и Листеру.
Если в ходе этого поиска сроки решения задач не ограничивать, команда теряет фокус и начинает делать всякую ненужную побочную фигню, и проект заболачивается, а потом и умирает.
Но если команду и ее разработчиков начать подгонять сверху и спускать какие-то сроки, это создаст у разработчиков понимание, что конечный результат от них не зависит, и вместо пылающих глаз мы получим горящие пуканы и, опять же, торможение и гибель проекта. Это один из идеальных сценариев «травли команд» по Бруксу и Листеру. Именно в таких условиях разработчики начинают раздувать сроки и бездельничать, сделав переоцененную задачу — им нужно прикрыть задницу, а не построить вместе с командой крутой продукт.
Тонкая грань максимальной эффективности команды — это режим, в котором команда полностью вовлечена и все участники чувствуют, что результат зависит только от них, берут на себя личную ответственность за результат. При этом темп поддерживается максимально высокий, сроки поставки фич и проверки гипотез остаются управляемыми. Нужно, чтобы команда оценивала сроки работы над задачами, чтобы она по-честному могла взять на себя ответственность за обоснованные сроки поставки.
Таким образом, автор, по сути, призывает к тому, чтобы команды Контура работали расслабленно, без огонька. А значит и без шансов сделать что-то действительно крутое.
В чем и виновен :)
Спринт обычный, фиксированный. Сроки оцениваются не для спринта, а для фич, которые бывают разными и могут делаться в несколько спринтов или просто уезжать вперед из-за нехватки времени в текущем или следующем.
То, что команда сама выполняет функции менеджера — дает огромный буст к мотивации и чувство драйва. То есть, счастливы и заказчики, и команда. Именно это невозможно при подходе, описанном автором оригинального поста.
Разумеется, при этом команда может обосновать эти сроки заказчику, либо уже заслужила его доверие.
Если заказчик так работать не может, то все скатывается к сценариям, описанным автором поста, с соответствующим отношением к неадекватному заказчику.
Оценка каждой задачи — необходимый источник данных, чтобы назвать конечный срок, но никто в здравом уме не суммирует их механически. И команда никогда не подпишется под такой оценкой. И автор поста тоже пишет, что так делают только неадекватные менеджеры.