Блог

Scrum и agile методы работы над проектами цифровизации: едим слона по частям

Успех цифровизации организации во многом зависит от строгости и точности формулировки задачи разработчикам

В качестве иллюстрации приведем часть известной шутки под названием - "как узнать - является ли человек программистом"

Нужно дать задачку и выслушать ответы:

"Буратино дали 3 яблока
Два он отдал Мальвине
Сколько яблок у него осталось?"
Ответы:
  1. Неизвестно сколько яблок было у Буратино до того, как ему дали 3 яблока
  2. Неизвестно два "чего" он отдал Мальвине
  3. Неизвестно, что подразумевается под процессом "отдал" и результат этого процесса (может Мальвина не взяла)
и т.д.
Можно, конечно, смеяться над придурковатостью программистов

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

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

Традиционно ключевым документом, содержащим замыслы и хотелки заказчика принято считать такую штуку как - Техническое задание (ТЗ)

Как показывает практика - 100% полных ТЗ для разработчиков человек создать не способен

Равно как и не способен человек создать хотя бы ТЗ, которое описывало бы в деталях объем работ на ~60-70%

Это медицинский факт

Не будем даже затрагивать тему языка, которым по уму должно быть оформлено ТЗ. Данный пост о том, что даже на уровне задумки человек (или коллектив) не способен полностью сформулировать требования к разрабатываемой системы - к нюансом ее деталей и сценариев ее поведения/использования

Но задачу по цифровизации и повышению эффективности деятельности никто же не отменял!

В качестве компромиссного решения в области взаимодействия заказчика и разработчика человечество "докатилось" до гибких методов взаимодействия, которые принято называть SCRUM или AGILE методами работы над проектом

Если на пальцах, то суть подхода заключается в том, что и заказчик и разработчик на берегу договариваются "есть слона по частям"

В процессе нашей практики мы выработали следующую методологию работы над проектами в области взаимодействия с заказчиком:

1. На берегу проговаривается какое веб-приложение создается

  • Какие бизнес-задачи решаются?
  • Кто пользователи веб-приложения?
  • Какие интеграции потребуются?

2. В качестве первого (а затем и последующих) этапа выделяется "стартовый кусок слона", который и начинается с дотошностью детализироваться в диалоге с заказчиком в духе
  • Сколько яблок в начале у Буратино?
  • Буратино и Мальвина - это разные сущности или копии одного экземпляра?
и т.д.

Данный подход позволяет решать ключевую задачу - на практике осуществлять цифровизацию организации - с минимальными рисками и разумными бюджетами

Субъективно - данный подход является оптимальным для реализации проектов по цифровизации деятельности

В своей практике мы сталкивались с примером десятков проектов, в которых в организации сперва несколько лет писалось огромное ТЗ (100+ страниц), затем примерно столько же проводились наивные тендеры на поиск тех, кто, по замыслу авторов - сможет воплотить содержание данного ТЗ в жизнь

Успешных примеров воплощения указанных ТЗ в жизнь - мы не знаем

И падишах и ишак - когда-нибудь умрут

Читайте далее - риски коробочных решений

2024-01-26 15:08