Предлагаю к вашему вниманию новый подход в разработке программного обеспечения. Хотите плачьте, хотите нет. Но этот подход укоренился в инженерии программного обеспечения, и я всего лишь констатирую факт и озвучиваю ту реальность, которая у нас есть. Пока продумывыется видение новой методологии. По аналогии с устаревшим Аджайлом я положил 4 ценности в базу нового подхода. Буду рад услышать ваше мнение, а может быть вы уже это используете и поэтому можете поделиться всеми положительными чертами подхода.
Манифест пост-советского вотерфола (aka новый Аджал):
• Экстрасенсорное управление требованиями, важнее постоянной коммуникации с клиентом
• Грандиозные возможности программы, важнее удовлетворения потребностей клиента
• Руководство только первоначальными требованиями, важнее постоянных уточнений
• Изолирование всех участников проекта и улучшенный документооборот, важнее потери времени на обсуждения
Итак, пободробнее:
Приходиться слышать, что выскоквалифицированные инженеры не должны требовать от заказчика требования. Да и вообще уменьшить коммуникацию с ним. Подход заключается в четкой декомпозиции и распределении ответственности. Есть сейлз (продавец), он вытряс с заказчика ТЗ. Сейлз передал это в разработку. Мягко говоря не поняв предлагаемого решения получив эстимейты он продал это клиенту. Руководство поставило строгую изоляцию на коммуникацию между командой и клиентом и отдала все полноту ответственности за создание команде разработке.
А ведь и верно. Достаточно получить базовое техническое задание, а дальше начинать разработку аналитики и программирования из своей экспертизы и знаний. Ведь они профессионалы, могут разработать несколько вариантов и предложить это заказчику. Бытует мнение, что только такие команды выживают в нашем суровом мире. Конечно вы прикладываете некоторые экстрасенсорные возможности считывания мыслей заказчика на расстоянии. Но не беда, гибкое решение покрытое тестами и продуманными решениями только от этого усилиться. И вот только такие команды доставляют истинное удовольствие клиенту. Команды, которые на базе минимальной информации, в изоляции от заказчика (потребителя продукта) создают высококласные продукты. Конечно они создают. Вероятность очень высока. Будут применяться высокоэффективные методики — TDD, парное программирование и т.п. Все как в настоящем Agile. И все будут довольны. Но под «все» подразумевается команда разработки, так они сделали продукт своей мечты. В продукте все фичи, которые команда могла только вообразить, которые могут потенциально потребоваться клиенту. Все тесты проходят. Все радуются и ждут с нетерпеньем появление клиента в офисе для презентации продукта и подписания факта сдачи…
И тут за несколько месяцев разработки. После подписания ТЗ появляется клиент. Торопясь, разговариваия по телефону заходит в офис. Его проводят в команту для презентации. Вся команда с нетерпением ждёт радостных вздохов клиента и предвкушает неимоверные бонусы. Все ликуют.
Заказчик участвует в презентации. Команда и заказчик окружили клиентскую машину. Руководители разработки с помощью профессиональных инженеров объясняют и демонстрируют результат. За радостными объяснениями всего многообразия продвинутого функционала. За пылкими объяснениями. Народ потерял из виду заказчика. Заказчик уже не стоит с командой заинтересовано. Он уже давно сел. В его глазах пропал огонёк, с которым он проснулся сегодня. Он уже думает как рапортовать своему руководству о результатах работы… И когда презентация подходит к концу команда поворачивается к нему и спрашивает — ну как? На что получает в ответ только один вопрос, шопотоп, с едва заметными опущеными уголками рта… «Что это?».
Итак, если вы супер команда разработчиков и хотите добиться таких же потрясающих результатов. Вот вам манифест:
Манифест пост-советского вотерфола:
• Экстрасенсорное управление требованиями, важнее постоянной коммуникации с клиентом
• Грандиозные возможности программы, важнее удовлетворения потребностей клиента
• Руководство только первоначальными требованиями, важнее постоянных уточнений
• Изолирование всех участников проекта и улучшенный документооборот, важнее потери времени на обсуждения
Незначительные комментарии.
«Экстрасенсорное управление требованиями, важнее постоянной коммуникации с клиентом». Хороший менеджер понимает, удовлетворение клиента будет лишь тогда. Когда он не будет отвлекаться на постоянные встречи, уточнения и т.п. Эффект «волшебной палочки» самое лучшее решение в борьбе с конкурентами. К тому же любой менеджер понимает, что он нанял инженеров с высшими образованиями, с красными дипломами и т.д. Поэтому эти ребята обязательно сами все поймут и сделуют по первому классу.
«Грандиозные возможности программы, важнее удовлетворения потребностей клиента». Отдав всю ответственность в команду. Мы мотивируем команду на свершения! Никаких ограничений. Только базовый набор требований заказчика, которые команда должна продумать и предусмотреть все возможные потенциальные потребности клиента как сейчас так и в будущем. Ведь хороший менеджер понимает ограничение команды и её творческого потенциала — это плохо отразиться на мотивации и качестве. Дайте бразды правления в команду! И команда сделает вам конфетку со всем немыслимым функционалом.
«Руководство только от первоначальными требованиями, важнее постоянных уточнений». Пересекается с первым. Лишь напоминает, что клиента не стоит тревожить. Не стоит разрушать его мечту о супер-программе. Он все что хотел он все написал. Теперь слово за профессионалами. Не зря же у инженер-программистов зарплата выше чем у простых инженеров.
«Изолирование всех участников проекта и улучшенный документооборот, важнее потери времени на обсуждения». Так и только так можно контролировать процесс. У каждого своя зона ответственности. Все подочётны своим руководителям. Руководители команд сообщают мне о статусе. Никаких пересечений! Только специализация и идеальная реализация изолированных частей в конце продукта даст отличный результат. К тому же не нужно сейлзу понимать как будет выглядить программа. А программистам не нужно тратить время на пустую болтавню с клиентом. Хороший менеджер платит за работу и строки кода — и только это реальная работа.
Если вы узнаёте себя в таком описании буду рад услышать ваш опыт и те плюсы, которые даёт предложенный мною подход.
PS. Конечно, если такой подход вам не очень понравился, вы можете присоединиться к Аджайл сообществу. О нём и его ценностях я писал — здесь
Манифест пост-советского вотерфола (aka новый Аджал):
• Экстрасенсорное управление требованиями, важнее постоянной коммуникации с клиентом
• Грандиозные возможности программы, важнее удовлетворения потребностей клиента
• Руководство только первоначальными требованиями, важнее постоянных уточнений
• Изолирование всех участников проекта и улучшенный документооборот, важнее потери времени на обсуждения
Итак, пободробнее:
Приходиться слышать, что выскоквалифицированные инженеры не должны требовать от заказчика требования. Да и вообще уменьшить коммуникацию с ним. Подход заключается в четкой декомпозиции и распределении ответственности. Есть сейлз (продавец), он вытряс с заказчика ТЗ. Сейлз передал это в разработку. Мягко говоря не поняв предлагаемого решения получив эстимейты он продал это клиенту. Руководство поставило строгую изоляцию на коммуникацию между командой и клиентом и отдала все полноту ответственности за создание команде разработке.
А ведь и верно. Достаточно получить базовое техническое задание, а дальше начинать разработку аналитики и программирования из своей экспертизы и знаний. Ведь они профессионалы, могут разработать несколько вариантов и предложить это заказчику. Бытует мнение, что только такие команды выживают в нашем суровом мире. Конечно вы прикладываете некоторые экстрасенсорные возможности считывания мыслей заказчика на расстоянии. Но не беда, гибкое решение покрытое тестами и продуманными решениями только от этого усилиться. И вот только такие команды доставляют истинное удовольствие клиенту. Команды, которые на базе минимальной информации, в изоляции от заказчика (потребителя продукта) создают высококласные продукты. Конечно они создают. Вероятность очень высока. Будут применяться высокоэффективные методики — TDD, парное программирование и т.п. Все как в настоящем Agile. И все будут довольны. Но под «все» подразумевается команда разработки, так они сделали продукт своей мечты. В продукте все фичи, которые команда могла только вообразить, которые могут потенциально потребоваться клиенту. Все тесты проходят. Все радуются и ждут с нетерпеньем появление клиента в офисе для презентации продукта и подписания факта сдачи…
И тут за несколько месяцев разработки. После подписания ТЗ появляется клиент. Торопясь, разговариваия по телефону заходит в офис. Его проводят в команту для презентации. Вся команда с нетерпением ждёт радостных вздохов клиента и предвкушает неимоверные бонусы. Все ликуют.
Заказчик участвует в презентации. Команда и заказчик окружили клиентскую машину. Руководители разработки с помощью профессиональных инженеров объясняют и демонстрируют результат. За радостными объяснениями всего многообразия продвинутого функционала. За пылкими объяснениями. Народ потерял из виду заказчика. Заказчик уже не стоит с командой заинтересовано. Он уже давно сел. В его глазах пропал огонёк, с которым он проснулся сегодня. Он уже думает как рапортовать своему руководству о результатах работы… И когда презентация подходит к концу команда поворачивается к нему и спрашивает — ну как? На что получает в ответ только один вопрос, шопотоп, с едва заметными опущеными уголками рта… «Что это?».
Итак, если вы супер команда разработчиков и хотите добиться таких же потрясающих результатов. Вот вам манифест:
Манифест пост-советского вотерфола:
• Экстрасенсорное управление требованиями, важнее постоянной коммуникации с клиентом
• Грандиозные возможности программы, важнее удовлетворения потребностей клиента
• Руководство только первоначальными требованиями, важнее постоянных уточнений
• Изолирование всех участников проекта и улучшенный документооборот, важнее потери времени на обсуждения
Незначительные комментарии.
«Экстрасенсорное управление требованиями, важнее постоянной коммуникации с клиентом». Хороший менеджер понимает, удовлетворение клиента будет лишь тогда. Когда он не будет отвлекаться на постоянные встречи, уточнения и т.п. Эффект «волшебной палочки» самое лучшее решение в борьбе с конкурентами. К тому же любой менеджер понимает, что он нанял инженеров с высшими образованиями, с красными дипломами и т.д. Поэтому эти ребята обязательно сами все поймут и сделуют по первому классу.
«Грандиозные возможности программы, важнее удовлетворения потребностей клиента». Отдав всю ответственность в команду. Мы мотивируем команду на свершения! Никаких ограничений. Только базовый набор требований заказчика, которые команда должна продумать и предусмотреть все возможные потенциальные потребности клиента как сейчас так и в будущем. Ведь хороший менеджер понимает ограничение команды и её творческого потенциала — это плохо отразиться на мотивации и качестве. Дайте бразды правления в команду! И команда сделает вам конфетку со всем немыслимым функционалом.
«Руководство только от первоначальными требованиями, важнее постоянных уточнений». Пересекается с первым. Лишь напоминает, что клиента не стоит тревожить. Не стоит разрушать его мечту о супер-программе. Он все что хотел он все написал. Теперь слово за профессионалами. Не зря же у инженер-программистов зарплата выше чем у простых инженеров.
«Изолирование всех участников проекта и улучшенный документооборот, важнее потери времени на обсуждения». Так и только так можно контролировать процесс. У каждого своя зона ответственности. Все подочётны своим руководителям. Руководители команд сообщают мне о статусе. Никаких пересечений! Только специализация и идеальная реализация изолированных частей в конце продукта даст отличный результат. К тому же не нужно сейлзу понимать как будет выглядить программа. А программистам не нужно тратить время на пустую болтавню с клиентом. Хороший менеджер платит за работу и строки кода — и только это реальная работа.
Если вы узнаёте себя в таком описании буду рад услышать ваш опыт и те плюсы, которые даёт предложенный мною подход.
PS. Конечно, если такой подход вам не очень понравился, вы можете присоединиться к Аджайл сообществу. О нём и его ценностях я писал — здесь
