Где-то на задворках сада с прекрасными реализованными проектами у каждого из нас есть уголок, в котором сложены мёртвые проекты. Речь не о тех, которые просуществовали какое-то время и прожили всю свою прекрасную жизнь с момента идеи, пройдя анализ, реализацию, тестирование, отправленные в свободное плавание с поддержкой и регулярными доработками, не о тех, которые выведены из эксплуатации, принеся кучу профита. Я о проектах, которые были реализованы, а после остались с двумя первыми записями, которые внес пользователь при их первом и, к сожалению, последнем запуске. Кто-то может сказать, что это в любом случае опыт, и выдаст то, что его уголок с такими проектами не пустует. Но в большинстве случаев это ведёт, как минимум, к демотивации команды, как максимум — к потере доверия. Некоторые из проектов можно перепрофилировать, разобрать на части и использовать в будущем, часть останется безмолвным напоминанием. И всё же, почему такое происходит? — Изменение процесса. Да, такое случается. Продукт разрабатывался, а бизнес в свою очередь не стоял на месте, и в результате в продукте уже нет потребности. — Слабый анализ потребностей. Тут надо делать выводы, разбирать, почему это произошло, и делать контроли для недопущения в будущем. Был случай, аналитик записал потребность со слов только одного сотрудника, и в результате мы получили инструмент, идеально заточенный под одного человека. — Изначально неспособный к жизни инструмент. Такое бывает, когда спонсор принимает решение без сбора обратной связи и со словами «Это нужно, это точно будет работать» запускает проект. — Не учли всех участников процесса. Это относится к пункту «Слабый анализ», но требует отдельного акцента внимания. Очень неприятно будет, после того как вы выкатите в продакт, узнать, что не учли всех участников процесса и часть из них болтается за бортом вашей прекрасной автоматизации. — И моё любимое «Я посчитал, что так будет лучше». Инициатива — это хорошо, но она должна быть умеренной и по делу. Требования, составленные аналитиком, должны быть согласованы не только заказчиком, но и руководителем аналитика, а потом результаты проверены лидом разработки. Есть исключения для сотрудников, которые отвечают всем вашим стандартам качества. И вот история: принимаем реализованный инструмент и замечаем, что часть функционала работает не так, как надо. Руководитель разработки убеждает, что всё согласно требованиям. И вот в момент открытия требований один из разработчиков признался, что кое-что переделал, так как посчитал процесс не оптимальным и он должен по-другому работать. Можно ли избежать вышеописанного? Да, можно, правильно построив процесс. За последние несколько лет в моих командах такого не встречалось. Будет ли это у меня в будущем? Точно будет, но оно будет проанализировано и записано в карту рисков. Поэтому зарезервируйте побольше места для своего уголка и относитесь к каждому такому проекту как к полезному опыту.