Будучи вовлеченным уже более десятка лет в индустрию автоматизации бизнеса, даже и представить не мог, что когда-нибудь буду писать о таких базовых вещах. “Если можете не писать - не пишите”, говорил великий русский классик. Следуя этому совету, все же придется написать...
С чего все начинается. Целью любой автоматизации является повышение эффективности какой-либо деятельности. Есть сотни показателей эффективности, но в основном речь идет об удешевлении какого-либо процесса и/или снижении рисков, или, как принято говорить, снижении “человеческого фактора”. По большому счету существует два варианта этого добиться при помощи внедрения софта:
- для типовой деятельности наверняка уже существуют готовые продукты;
- для уникальной деятельности приходится окунаться в мир разработки программного обеспечения.
На самом деле есть еще третий путь, когда наша деятельность достаточно типовая, но с уникальными аспектами. В этом случае возможно взять готовый продукт и доработать под себя. Такая возможность сильно зависит от продукта и от вендора. Конфигурации 1С служат отличным и успешным примером такого варианта, но они существуют далеко не для всего.
У каждого из перечисленных направлений есть свои плюсы и минусы. Очевидно, что разработка решения под себя - это наиболее гибкий подход, который позволяет идеально встроится в существующие бизнес-процессы без их значительной трансформации. Также разработанная система будет собственностью и активом компании - так что затраты на заказную разработку можно рассматривать в разрезе инвестиций. Минусом является, собственно, размер этих самых затрат, которые зачастую кратно меньше при закупке и внедрении готового продукта.
Предположим, что взвесив все за и против, выбран вариант разработки собственного уникального решения. Мы будем придерживаться именно этого сценария.
ТЗ и выбор исполнителя. Чаще всего все идет по классическому сценарию.
Вокруг изначальной идеи\проблемы начинает писаться техническое задание (ТЗ). Зачастую первая версия ТЗ пишется инициативной группой и его содержание четко обрисовывает поставленную задачу. Предварительно делается внутренняя оценка на реализацию, которая вполне всех устраивает и проекту дают дальнейший ход.
Затем в общем-то уже готовое ТЗ направляется на согласование во все смежные (с точки зрения бизнеса) подразделения, ну и обязательно, надзорным службам: информационной, экономической, промышленной безопасности и пр. Когда кто-то уже взял на себя смелость выйти с проектом, то всем вокруг сразу хочется поразить мир своими идеями и претворить в жизнь ранее нереализованные потребности в рамках этого проекта. Обосновать почему оно должно оказаться в именно этом проекте - это уже отлаженный процесс. В конечном итоге уже на стадии подготовки ТЗ проект превращается в монстра Франкенштейна, но зато ... всеми согласованное. Инициатор в этом месте пребывает в состоянии удивленном и растерянном: с одной стороны победа! - ТЗ то согласовали, можно идти дальше, а с другой стороны доля изначальной идеи и реальной потребности в получившемся монстре, хорошо если составляет 5%, а то и вообще все изначальные требования инициативной группы признаются неприоритетными и вычищаются :).
Далее ТЗ идет в рынок на оценку: в одну, три или десять компаний, и получает примерную цену, за которую рынок готов воплотить идею в жизнь. Что это за число!? Почему так много!? Мы же прикидывали в 20 раз меньше! … так и планировалось сделать лишь 5% от написанного.
Далее конкурс. Конкурсная процедура с приоритетом цены есть опухоль, убивающая большинство качественных инициатив. Основополагающим фактором выбора победителя в большинстве конкурсов на внешнюю разработку является цена. Почти никогда заказчик не учитывает совокупную стоимость владения решением в горизонте 3-5-7 лет. Проект исполненный за рубль, вместо альтернативных двух, может стоить через три года уже все семь. Или кто-то думает что благородные исполнители будут пахать без шансов отбиться? Изучайте монетизацию потенциальных исполнителей!
Чем все заканчивается. Заканчивается все опытной эксплуатацией и внедрением, которые вскрывают ряд типовых проблем, так или иначе повторяющихся от случая к случаю:
- Сделано что-то, то что было в ТЗ, но это оказалось не нужно, а значит эксплуатация этого чего-то невозможна;
- Сделано что-то, то что нужно, вместо того что написано в ТЗ, но теперь сдача проекта невозможна, ведь формально требование не закрыто;
- Что-то сделать совсем не успели по причине сжатых сроков, что-то, казалось, совсем неприоритетное, но сдаваться, опять-же, приходится по исходному ТЗ...
В результате заказчик давит на исполнителя, тот формально закрывает требования и идет на перерасход в надежде отбиться следующим договором или просто сохранить репутацию. Формально закрытые требования не отвечают реальным потребностям конечных пользователей. Заказчик недоволен исполнителем, исполнитель недоволен заказчиком.
Что же пошло не так? Любой проект имеет много общего с живой природой. Он рождается и растет. Меняется и матереет. Устаревает. Сменяется новым поколением систем. Все как у Чарльза Дарвина в “Происхождении видов”. Фактически, написание всеобъемлющего ТЗ сразу отрезает эволюционный путь - путь развития удачных и затухания неудачных мутаций.
Следуя далее этой аналогии - описанный нами подход со всеобъемлющим ТЗ скорее является последователем антинаучного креационизма - мы проектируем землю и небо, живую и неживую природу и за 7 дней идем в промышленную эксплуатацию :). С этой точки зрения дарвинизм - это аджайл с time to market в 9 месяцев и итерацией длиною в человеческую жизнь, а креационизм - водопад (waterfall), где человек сразу сделан по образу и подобию (проекту) и не меняется с течением времени.
Здесь наверно и есть корень всех проблем. Если Человеку по проекту надо уметь летать в воздухе и плавать под водой, ему не нужны ни птичьи крылья ни рыбьи плавники. Придет время и Человек сам построит самолет и изобретет подводную лодку :).
Конкретнее, сам факт фиксации требований, функционала и бюджета с самого начала отменяет аджайл и колоссально оттягивает пресловутый “тайм ту маркет”. Да, мы можем побить наш водопад на пороги, но при этом гибкости это не добавит: сроки уже не сдвинуть, бюджеты не расширить, а функционал не пересогласовать.
Вот и получается: либо все, либо ничего. Все риски заложены в изначальном ТЗ и приняты исполнителем. Если они не сработают будет ВСЕ, сработают - будет НИЧЕГО. А учитывая раннюю стадию и неопределенность на этапе закладывания рисков, вероятность того что они выстрелят, саркастично выражаясь, ненулевая.
Прописные истины. Задумали идею? Не уверены, что это технологически возможно? Проведите R&D. Технология проверена? Стало понятно, что техническая реализация возможна? Сделайте MVP и убедитесь, что задуманное решение нужно и будет работать так, как вы полагали. Если почитать историю стартапов-единорогов, то в 99% случаев сработала не изначальная идея, а результат работы с рынком, с пользователями. Проверили гипотезу - можно реализовывать проект.
Часто задают вопрос “А что если R&D не сработает и MVP не полетит? Меня ж уволят!”. Может это и хорошо? Если компания не может адекватно воспринимать реальность, может и ну еe, такую компанию? В целом, по нашему опыту российский бизнес в последние годы становится более толерантен к такого рода рискам.
Все это тысячу раз сказано, написано и кажется вполне очевидным. Однако, не работает. Почему? Так сложилось. Есть процедуры, есть регламенты, есть законодательные аспекты. Ничего из перечисленного списка не поддерживает эти самые прописные истины. Так и живем...
Что мы с этим всем делаем. Надо понимать, что традиционный поиск виноватого смысла не имеет. И со стороны заказчика и со стороны исполнителя (кем мы и являемся) есть своя правда. Так получается, что каждый шаг делается правильно и осознанно, но вот в результате тропа ведет не туда. Мы, уже более 10 лет делаем разработку на заказ и за сотни выполненных проектов выработали некоторые рецепты, которые помогают достигать положительных результатов снижая риски уйти не туда.
По возможности мы вовлекаемся на самом раннем этапе, когда есть то самое, изначальное ТЗ, созданное инициативной группой. Проверяем гипотезы с точки зрения их технической реализации, прикидываем архитектуру и ее ограничения в рамках предполагаемой нагрузки, требованиям к отказоустойчивости и пр. Тут у нас есть некий карт-бланш, как у вендора достаточно популярного и признанного open source Java фреймворка CUBA Platform, ведь бОльшее число наших клиентов изначально приходят к нам с твердым пониманием, что будут использовать для разработки именно платформу. Об этом подробнее можно узнать в этой статье. Уже на этом этапе заказчик формирует понимание какая "хотелка" как ударит по карману.
Опять же в силу особенностей нашего бизнеса, в большинстве случаев мы имеем дело с компаниями в которых есть внутренний отдел разработки. Мы всячески поддерживаем так называемый in-house, ведь именно это подразделение является клеем между бизнесом и технологиями. Зачастую у этих ребят нет сверхглубокого понимания технических аспектов, но они обладают уникальным свойством разговаривать с бизнесом на их языке, а с нами на нашем, понимая сложность в реализации поставленных задач. Мы максимально плотно взаимодействуем с такого рода подразделениями и, в свою очередь, передаем им свои компетенции в сфере разработки ПО, архитектур и пр. Вообще в каждом проекте, мы ставим целью в какой-то момент стать ненужным своему заказчику передав все дела их отделам разработки ПО и вовлекаться только при решении экстраординарных задач.
Начинаем с малого. Начинаем с MVP, в который включаем наиболее необходимый функционал, а также наиболее узкие места, требующие проверки. Именно это и будет базисом дальнейшей эволюции, поэтому необходимо взвешенно подбирать функционал, попадающий в прототип. С юридической точки зрения MVP - отдельный договор, конкурс, закупка, кому как привычнее называть :). MVP закладывает основы наиболее негибких частей приложения, включая его базовую архитектуру. Это сверхответственный момент и тут наше вовлечение обычно максимально. Важно чтобы MVP сразу перешел в использование реальным пользователям, а не отлеживался на полке.
На следующем этапе начинается более планомерная работа по разработке первой релизной версии. Тут уже в полный рост включаются ребята из структур внутренней автоматизации, при наличии таковых. К самому релизу у них уже есть полное понимание инфраструктуры процесса разработки (VCS, CI, тестовое окружение, автотесты, релизные процессы, развертывание, база знаний, документирование, issue tracker и все все все).
С точки зрения регламентных процедур и бюджетов, идеально завершить MVP к концу отчетного периода, перед формированием бюджета на следующий. Т.к. к этому моменту попасть в оценку становится гораздо проще!
А теперь самое важное. Открытость и прямота - это обязательные ингредиенты успеха. Были случаи когда нам пытались сказать “делайте так как мы сказали, мы вам за это деньги платим”. Нет, деньги вы нам платите не за это, а за конечный результат, который не будет соответствовать ожиданиям если “делайте так”. У нас есть аргументы, давайте объяснимся и придем к общим выводам! Обе стороны должны иметь волю и быть предельно открыты и прямолинейны по отношению друг к другу. Нам проще отказаться от проекта, если мы сомневаемся в его целесообразности и успехе.