Успех цифровизации организации во многом зависит от строгости и точности формулировки задачи разработчикам
В качестве иллюстрации приведем часть известной шутки под названием - "как узнать - является ли человек программистом"
Нужно дать задачку и выслушать ответы:
"Буратино дали 3 яблока
Два он отдал Мальвине
Сколько яблок у него осталось?"
В качестве иллюстрации приведем часть известной шутки под названием - "как узнать - является ли человек программистом"
Нужно дать задачку и выслушать ответы:
"Буратино дали 3 яблока
Два он отдал Мальвине
Сколько яблок у него осталось?"
Ответы:и т.д.
- Неизвестно сколько яблок было у Буратино до того, как ему дали 3 яблока
- Неизвестно два "чего" он отдал Мальвине
- Неизвестно, что подразумевается под процессом "отдал" и результат этого процесса (может Мальвина не взяла)
Можно, конечно, смеяться над придурковатостью программистов
Но тут важно отдавать себе отчет, что компьютер - это просто очень мощный калькулятор. На уровне здравого смысла вести с ним диалог - бесполезно
В этом плане можно смотреть на разработчиков - как на переводчиков человеческих замыслов и хотелок на "компьютерный язык". Отсюда и, казалось бы - дурацкие вопросы про "два чего отдал Буратино?"
Традиционно ключевым документом, содержащим замыслы и хотелки заказчика принято считать такую штуку как - Техническое задание (ТЗ)
Как показывает практика - 100% полных ТЗ для разработчиков человек создать не способен
Равно как и не способен человек создать хотя бы ТЗ, которое описывало бы в деталях объем работ на ~60-70%
Это медицинский факт
Не будем даже затрагивать тему языка, которым по уму должно быть оформлено ТЗ. Данный пост о том, что даже на уровне задумки человек (или коллектив) не способен полностью сформулировать требования к разрабатываемой системы - к нюансом ее деталей и сценариев ее поведения/использования
Но задачу по цифровизации и повышению эффективности деятельности никто же не отменял!
В качестве компромиссного решения в области взаимодействия заказчика и разработчика человечество "докатилось" до гибких методов взаимодействия, которые принято называть SCRUM или AGILE методами работы над проектом
Если на пальцах, то суть подхода заключается в том, что и заказчик и разработчик на берегу договариваются "есть слона по частям"
В процессе нашей практики мы выработали следующую методологию работы над проектами в области взаимодействия с заказчиком:
1. На берегу проговаривается какое веб-приложение создается
2. В качестве первого (а затем и последующих) этапа выделяется "стартовый кусок слона", который и начинается с дотошностью детализироваться в диалоге с заказчиком в духе
Данный подход позволяет решать ключевую задачу - на практике осуществлять цифровизацию организации - с минимальными рисками и разумными бюджетами
Субъективно - данный подход является оптимальным для реализации проектов по цифровизации деятельности
В своей практике мы сталкивались с примером десятков проектов, в которых в организации сперва несколько лет писалось огромное ТЗ (100+ страниц), затем примерно столько же проводились наивные тендеры на поиск тех, кто, по замыслу авторов - сможет воплотить содержание данного ТЗ в жизнь
Успешных примеров воплощения указанных ТЗ в жизнь - мы не знаем
И падишах и ишак - когда-нибудь умрут
Читайте далее - риски коробочных решений
Но тут важно отдавать себе отчет, что компьютер - это просто очень мощный калькулятор. На уровне здравого смысла вести с ним диалог - бесполезно
В этом плане можно смотреть на разработчиков - как на переводчиков человеческих замыслов и хотелок на "компьютерный язык". Отсюда и, казалось бы - дурацкие вопросы про "два чего отдал Буратино?"
Традиционно ключевым документом, содержащим замыслы и хотелки заказчика принято считать такую штуку как - Техническое задание (ТЗ)
Как показывает практика - 100% полных ТЗ для разработчиков человек создать не способен
Равно как и не способен человек создать хотя бы ТЗ, которое описывало бы в деталях объем работ на ~60-70%
Это медицинский факт
Не будем даже затрагивать тему языка, которым по уму должно быть оформлено ТЗ. Данный пост о том, что даже на уровне задумки человек (или коллектив) не способен полностью сформулировать требования к разрабатываемой системы - к нюансом ее деталей и сценариев ее поведения/использования
Но задачу по цифровизации и повышению эффективности деятельности никто же не отменял!
В качестве компромиссного решения в области взаимодействия заказчика и разработчика человечество "докатилось" до гибких методов взаимодействия, которые принято называть SCRUM или AGILE методами работы над проектом
Если на пальцах, то суть подхода заключается в том, что и заказчик и разработчик на берегу договариваются "есть слона по частям"
В процессе нашей практики мы выработали следующую методологию работы над проектами в области взаимодействия с заказчиком:
1. На берегу проговаривается какое веб-приложение создается
- Какие бизнес-задачи решаются?
- Кто пользователи веб-приложения?
- Какие интеграции потребуются?
2. В качестве первого (а затем и последующих) этапа выделяется "стартовый кусок слона", который и начинается с дотошностью детализироваться в диалоге с заказчиком в духе
- Сколько яблок в начале у Буратино?
- Буратино и Мальвина - это разные сущности или копии одного экземпляра?
Данный подход позволяет решать ключевую задачу - на практике осуществлять цифровизацию организации - с минимальными рисками и разумными бюджетами
Субъективно - данный подход является оптимальным для реализации проектов по цифровизации деятельности
В своей практике мы сталкивались с примером десятков проектов, в которых в организации сперва несколько лет писалось огромное ТЗ (100+ страниц), затем примерно столько же проводились наивные тендеры на поиск тех, кто, по замыслу авторов - сможет воплотить содержание данного ТЗ в жизнь
Успешных примеров воплощения указанных ТЗ в жизнь - мы не знаем
И падишах и ишак - когда-нибудь умрут
Читайте далее - риски коробочных решений
