Соответствие системы показателей (стимулирования) и гибких методологий управления

В докладе представлены различные аспекты и проблемы продуктовой разработки, а также сделаны попытки обобщения с предыдущими опытами управления в проектной среде: веб-студии, интернет-магазины и т.п.

На основе saas-продукта управления задачами рассматриваются:
1. Коммуникация между департаментами разработки и продуктов;
2. Применение Скрам и Канбан методов для выравнивания нагрузки и попадания новых функций в очередной релиз;
3. Противоречие системы стимулирования и основ гибкой методологии;
4. Оценка приоритетов новых разработки новых функций и рефакторинга старых.

Что нового в докладе? И кому будет интересно?

Чтобы привлечь внимание нужно выдвинуть? какой-то очень спорный тезис. Часто это необходимо? чтобы заставить посмотреть по новому на привычные до боли процессы. В ходе доклада я покажу всё дерево причинно-следственных связей (технология мыслительных процессов), которое докажет, что тезисы не такие уж спорные.

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

Основные тезисы:
1. Гибкие методы разработки позволяют сохранить драйв в команде, а не ускорить процесс. Именно вовлеченность является ограничением, чтобы продукт развивался в правильном направлении. Особенно это важно, когда продукт "уже не молодой". Правильное внедрение гибких методологий позволяет соблюсти основные факторы вовлеченности: интересные задачи, правильный начальник (продект, продакт, тимлид), справедливая система вознаграждения. Если противоречия основным факторам вовлеченности нет - ваш аджайл правильный. Есть противоречия - формальный.
2. Оценка времени задач является ложным целевым показателем при разработке программного продукта. В проектном управлении говорится, что превращение интервальных оценок в обязательства приводит к раздуванию оценок. В продуктовом управлении, мы можем сказать, что опираться на оценку длительности выполнения задач совершенно вредная практика. Она ведет к росту ненужной или сырой функциональности. Большинство творческой активности мгновенно. Это мгновенные озарения, а не алгоритмический процесс, когда каждая мысль занимает "какое-то время". Для самолета важно сколько занимает время регистрации и поездка в аэропорт и обратно, а не сам полет. Подумайте об этом. И вспомните, что производительность разных программистов отличается не в разы, а в сотни и тысячи раз. Для управления активностями, для которых время не сутевой показатель, важен пересмотр приоритетов примерно также как это происходит в ГТД.
3. Управление требованиями не дает результатов потому, что нужен "мегаопыт", чтобы во внятные формулировки заложить и извлечь один и тот же смысл. При этом важно понимать не только требования, которые относятся к продукту, а и те, которые точно не относятся. Видение нескольких вариантов и границ применения не равно написанию одного варианта требований. Этот процесс касается не только аналитиков и продактов. Поэтому правильный фокус не в том, чтобы писать красивые документы. Их невозможно написать. Фокус, чтобы у конечного исполнителя была явная связь между идеей продукта, выгодой пользователя и "как-то заформулированными" требованиями. Это связь возникает только при личном обсуждении. Чтобы добиваться правильного понимания уровень разработчика должен быть не узкоспециализированным, а широким. Людям нужно давать решать разноплановые и ответственные задачи. Если вы хотите роста своих разработчиков, и не очень хотите за то платить, дайте им возможность заниматься часть времени своими личными проектами. Скорость роста опыта - основной тормоз развития компаний. А готовых специалистов всегда мало.
4. В отличие от классического менеджмента, который применяется главным образом для систем массового обслуживания, умственный и творческий труд не позволяет быстрой замены людей. Для поддержания интереса и вовлеченности умственных работников необходимо, чтобы продукт был не до конца понятным. Если понятно, то не интересно. Попытки выстроить все процессы приводят к манипулируемости правилами. Простая математика и человеческий фактор. Мы это можем наблюдать на примере законов и их исполнения. Вопрос времени, когда система деградирует и энергии (и денег) на ее поддержание уходит больше, чем у незаоптимизированной и опроцешеной.