Если разработчиков не заставлять думать перед погружением в код — они будут «думать» в коде. Ясно, что из этого получится, постоянные доработки и баги. Часто разработчик с горящими глазами бегущий к консоли пропадал на неделю, когда я просил его набросать схему интерфейсов и логическую модель данных.
Дело в том, что не всегда нетехнический ProductOwner может принять адекватное решение, делать рефакторинг или нет. Ему нужно добавлять фичи побольше и побыстрее — желательно мгновенно. Я в многих проектах видел рефакторинг, отложенный на потом по причине расстройства желудка у руководителя проекта, никогда не выполнялся, затем этот РП увольнялся и с кучей г… на приходилось разбираться техническому директору.
Когда вы заметите ошибку, может быть уже поздно — пройдете точку невозврата. Уровень квалификации IT-специалистов не просто оценить, особенно на нашем российском рынке.
Конечно «бить морду» это метафора. Цель стати — заставить задуматься о последствиях сразу, чтобы не провалить проект.
Техбэклог — это предложения команды по поводу как потратить время, не добавляя функционал. Тимлид наверно будет активнее всего писать туда, т.к. когда требования меняются рефакторить придется часто. Чтобы тимлида не уволили за «трату времени впустую» — его прикрывает… техдир. Он должен быть сильнее ProductOwners, разумеется, по полномочиям и донести — что рефакторить нужно, иначе через год проект загнется к черту.
Рекомендую построить и запустить «каток» с использованием Agile/Scrum — стараетесь выбить себе одного/двух аналитиков, пишите детально продуманные формальные требования, насильственно оцениваете их на PlanningPoker с текущими разработчиками, набираете критическую массу требований, планируете релизы.
Может произойти чудо и топы наймут высокопрофессиональную команду разработчиков, которые закатив рукава перепишут/прорефакторят кучу г… на и вы сможете выпускать фичи долго и счастливо.
Это зависит от компании и проекта. Я отношусь к ProjectManager буквально — люди должны а) обоснованно выбрать проектный процесс (RUP, Iconix, Agile/Scrum, вопопад), б) подготовить план управления рисками и другие планы если нужно, в) расчитать бюджет, г) сформировать команду — но главная их задача — ДОСТИЧЬ ЦЕЛИ ПРОЕКТА в рамках бюджета. Сделать проект А в этом году за Б рублей. Сделает — остается, не сделает — уходит.
Не всегда менеджеры проекта общаются напрямую с Заказчиками. Общение может идти через руководителя проектного отдела, аналитиков, account-менеджеров.
Но в чем согласен с Вами, так это в удобной концепции Agile для руководителя проекта — открытость, желание решить задачи клиента, встреча изменений с распростертыми объятьями. Но к сожалению такая «свобода» таит сколько рисков, что ТЗшный подход нередко, в моей практике, приносил лучший результат.
Верно. Забыл описать данный тип менеджера, который желает понравится и заигрывает с Заказчиком, подминая под себя программистов — скорее политик, которому здоровье продукта через пару-тройку лет особо не важно.
Простой пример. Построен дом. Ведутся кровельные работы. Руководитель проекта, желая понравится, договаривается… поменять тип и число свай. Ему это конечно политически выгодно — но с точки зрения процесса строительства он не прав :-)
Архитектурно-строительные примеры из жизни учат нас тому, что ТЗ все-таки нужно, и менять цвет окон это одно, а прибивать унитаз к потолку — совсем другое. И за такие политические заигрывания с Клиентом, который сам не знает чего хочет, менеджера могут и в цемент залить :-)
Считается, что подкормка сахаром ослабляет семью, мы иногда подкармливали, иногда нет — поэтому можно оставить меда и побольше :-). Серу не насыпают в улей — ее дымом отравляют пчел.
Вот я про то же. Получается что «любви и не было» :-) Вы тут играйтесь в команду, а прийдет дядя и одним ударом размажет весь это коммунизм, если ему он станет невыгодным.
На самом деле есть проекты которые основаны именно на гуманности и профессионализме с большой буквы, где творчество и уважение к специалистам выше эффективности. Взять тот же линукс или FSF ;-) Но насколько они выгодны?
Интересную тему подняли… Я был в роли ProductOwner в одном большом веб-проекте (интернет-магазин и рефакторинг), число UserStories было порядка 500. Так вот, чтобы удержать это все дерево в актуальном и согласованном состоянии, мне потребовалось привлечь двух системных аналитиков + самостоятельно прорабатывал требования по несколько часов в день.
Чтобы не сойти с ума и удержать ситуацию под контролем, использовали все доступные инструменты UML: логические модели данных, диаграммы состояний, диаграммы активностей.
Параллельно вели прототип интерфейсов в Axure.
Что могу сказать — ситуация не выходила из под контроля. Но это хорошо, когда у вас с команде профессиональные аналитики. А иначе уверен — начнется коллапс требований и без Requirements Matrix уже не обойтись.
Какой я сделал вывод… Если проект сложный, используется много формальных алгоритмов, биллинг — Scrum может привести к катастрофе, если вовремя не привлечь аналитиков и не ввести в подготовке требований водопадный/итерационный подход.
Простая ассоциация — поисковики стараются ранжировать контент по его качеству, чтобы выдавать его на первом месте, как самый полезный, пользователям… И сразу появились «тунеядцы» под названием SEO-онанизаторы, прошу прощения, оптимизаторы, которые реально наносят вред здравой идее метрик полезности интернет-контента :-)
Борис, спасибо за статью. Есть над чем задуматься. А, как известно, половина успеха — это поставить правильный вопрос :-)
Ежедневные стендапы для разработчиков это разновидность, прошу прощения, секса по расписанию — нужно отчитываться, что ты делал/делаешь/будешь делать. Это снижает конечно мотивацию, имхо, но зато какая польза менеджеру от этого — команда в курсе о происходящих процессах, менеджер тоже, процесс прозрачен :-)
Отнюдь. Гибкие методологии с точки зрения инвестора/менеджера — очень привлекательны! В идеале я получаю оценки более-менее точные, демонстрации каждые 2-4 недели, постоянная гигиена проекта через рефакторинг, а через ретроспективы, я верю, что процесс самосовершенствуется. И конечно в коллективе по идее такая атмосфера создается, что уходить не хочется и наоборот должны приходить в команду :-)
Да и команда должна встречать изменения в требованиях… с радостью! Рай короче для ProductOwner, мечта, дримтим.
А какая альтернатива то? Сидеть и писать попобронирующие технические задания и кидаться артефактами через полудуплексные трубочки.
Но на практике найти путь в этот эффективный рай что-то сложно, одни мины вокруг и волки.
Значит при ВУЗах нужно создавать кузницы кадров или при крупных вендорах. Задача же проста до безобразия — мне в команду нужен квалифицированный программист, с сертификатом, которому я могу инвестиции.
Медиков сколько лет учат, а потом еще ординатура. И только потом можно брать в руки скальпель и кромсать :-). А что с программистом — коллеги учатся на живых проектах и ошибочно удаленные почки и случайно оставшиеся вне тела «лишние» органы приводят к разрушению, загниванию в конвульсиях проекта, в который инвесторы вложили много много денег.
Еще смущает мутность определения «равенства» членов команды. Неопытному разработчику, которому нужно учиться и учиться, «равенство» с опытным — конечно льстит. Опытный, который каждый день нянькается с отстающими, по-другому ощущает мнимое «равенство» — как дополнительную нагрузку по разжевыванию кашки :-) ИМХО о «равенстве» можно говорить лишь в контексте «равенства в отношении и уважении, как равноправного члена команды» (но, опять таки, далеко не равноценного, с различным коэффициентом взаимозаменяемости).
Эт же самое вкусное и наиболее частый кейс — попытаться запустить Scrum в неопытной команде. Один из работающих вариантов — жесткая иерархия профессиональной компетенции через «парное программирование» с руководителем отдела разработки :-) и другими профильными гуру в компании с последующим тотальным аудитом результатов спринтов.
Конечно «бить морду» это метафора. Цель стати — заставить задуматься о последствиях сразу, чтобы не провалить проект.
Т.е. вы проводите черту и дальше работаете правильно. Можно это апи начать покрывать тестами.
Может произойти чудо и топы наймут высокопрофессиональную команду разработчиков, которые закатив рукава перепишут/прорефакторят кучу г… на и вы сможете выпускать фичи долго и счастливо.
Не всегда менеджеры проекта общаются напрямую с Заказчиками. Общение может идти через руководителя проектного отдела, аналитиков, account-менеджеров.
Но в чем согласен с Вами, так это в удобной концепции Agile для руководителя проекта — открытость, желание решить задачи клиента, встреча изменений с распростертыми объятьями. Но к сожалению такая «свобода» таит сколько рисков, что ТЗшный подход нередко, в моей практике, приносил лучший результат.
Простой пример. Построен дом. Ведутся кровельные работы. Руководитель проекта, желая понравится, договаривается… поменять тип и число свай. Ему это конечно политически выгодно — но с точки зрения процесса строительства он не прав :-)
Архитектурно-строительные примеры из жизни учат нас тому, что ТЗ все-таки нужно, и менять цвет окон это одно, а прибивать унитаз к потолку — совсем другое. И за такие политические заигрывания с Клиентом, который сам не знает чего хочет, менеджера могут и в цемент залить :-)
На самом деле есть проекты которые основаны именно на гуманности и профессионализме с большой буквы, где творчество и уважение к специалистам выше эффективности. Взять тот же линукс или FSF ;-) Но насколько они выгодны?
Чтобы не сойти с ума и удержать ситуацию под контролем, использовали все доступные инструменты UML: логические модели данных, диаграммы состояний, диаграммы активностей.
Параллельно вели прототип интерфейсов в Axure.
Что могу сказать — ситуация не выходила из под контроля. Но это хорошо, когда у вас с команде профессиональные аналитики. А иначе уверен — начнется коллапс требований и без Requirements Matrix уже не обойтись.
Какой я сделал вывод… Если проект сложный, используется много формальных алгоритмов, биллинг — Scrum может привести к катастрофе, если вовремя не привлечь аналитиков и не ввести в подготовке требований водопадный/итерационный подход.
Борис, спасибо за статью. Есть над чем задуматься. А, как известно, половина успеха — это поставить правильный вопрос :-)
Да и команда должна встречать изменения в требованиях… с радостью! Рай короче для ProductOwner, мечта, дримтим.
А какая альтернатива то? Сидеть и писать попобронирующие технические задания и кидаться артефактами через полудуплексные трубочки.
Но на практике найти путь в этот эффективный рай что-то сложно, одни мины вокруг и волки.
Медиков сколько лет учат, а потом еще ординатура. И только потом можно брать в руки скальпель и кромсать :-). А что с программистом — коллеги учатся на живых проектах и ошибочно удаленные почки и случайно оставшиеся вне тела «лишние» органы приводят к разрушению, загниванию в конвульсиях проекта, в который инвесторы вложили много много денег.