Бывает, что после нескольких раундов обсуждений заказчик, который ранее приходил с запросом на создание приложения или сервиса для внутренних нужд, решается на такой проект самостоятельно, без привлечения внешнего центра разработки. «Есть представление, как оно должно работать. Есть кому писать код». Эти два аргумента говорят о том, что новый софт, вероятнее всего, будет делаться по остаточному принципу. И вместо средства решения конкретных бизнес-задач превратится в дорогой в развитии и содержании долгострой.
Пожалуй, избежать этого можно единственным способом - не поддаваться на компромиссы, которые я для себя сформулировал в виде пяти «НЕ», связанной с внутренней разработкой. Рассказывая о них, я время от времени будут приводить пример нюансы, которые раскрылись во время создания внутреннего проекта, который мы назвали «Спецификатор». Подобно конфигуратору на сайте автопроизводителя, он позволяет «собрать» перечень работ для заказчика. Мы применяем «Спецификатор» в при оценке проектов и в том числе благодаря ему эта оценка получается довольно точной - как по срокам, так и по бюджетам.
#1. Не начинайте без перечня задач
«Спецификатор» как внутренняя разработка стартовал без технического задания и с минимальными представлениями о взаимодействии с пользователем. «Хочу, чтобы «спека» собиралась из готовых модулей драг-энд-дропом!» - это была единственная вводная, касающаяся особенностей работы с разрабатываемым решением.
Надо ли говорить, что у нас не было ни представления о стеке, ни рекомендаций по стандартам в разработке, ни руководителя проекта, ни даже какой-то команды с намеком на постоянство? Мы сажали на проект специалиста со скамейки, говорили ему, какая фича нужна, а после того, как он ее сделает - хватались за голову: вроде работает, но не так.
Чтобы такого не произошло, имеет смысл сделать подготовительную работу и потратить на нее ресурсы тандема из бизнес-аналитика и тим-лида, либо специалиста, который совмещает в себе обе роли. С ними (или с ним) получится зафиксировать в документах, что вы хотите получить, и нарезать задачи по крайней мере для стартового этапа, пока проект не получит постоянного руководителя.
Да, надо быть реалистом: проект без РПшника возможен лишь какое-то время. Когда команда масштабируется (появляется больше одного бэкэндера и одного фронтэндера), роль проджект-менеджера становится практически неизбежной. Поэтому смиритесь: без РПшника реально сделать самые первые шаги в разработке - и то при условии, что нарезкой задач занимался толковый спец, который одинаково хорошо понимает, как работает голова у заказчика и разработчика. Фактически это и есть наш путь: несмотря на статус внутренней разработки, для «Спецификатора» в один прекрасный день нашлись и руководитель проекта, и более-менее стабильная по составу команда разработки - пусть и небольшая.
#2. Не забивайте на дизайн
Сюрприз: если привлечь специалиста по UI/UX именно на начальном этапе, это принесет гораздо больше пользы, чем если пригласить его на стадии придания решению товарного вида. Разработчик, которому объяснят, как именно пользователь будет взаимодействовать с сервисом или приложением, не получит шанса для слишком вольной реализации функциональности. В этом, а не в красивых кнопочках и ярких цветах интерфейса, состоит главная ценность роли UI/UX на старте проекта по внутренней разработке.
#3. Не допускайте излишней демократии
Демократия - обратная сторона четко зафиксированных стандартов разработки. Их отсутствие провоцирует большое количество мнений, которые коллеги высказывают относительно того, как должна работать та или иная фича. Мне приходилось видеть, как отдельные красноречивые разработчики убеждали руководителя проекта свернуть с намеченного пути. Случалось, что это приводило к жестким откатам и необходимости переписывать часть функциональности заново. В ходе разработки ранней версии «Спецификатора» мы сильно поплатились за игру в демократию: спонтанно реализованные функции стали блокерами для развития проекта. Пришлось всё ломать и переписывать заново.
#4. Не пренебрегайте автотестами
С моей точки зрения, автотесты - это сущность, которая входит в «профессиональный минимум» вообще любого разработчика или системного архитектора. Автотестами нужно подтверждать работоспособность фичей на каждом этапе развития. Мы поняли это лишь на этапе создания второй версии «Спецификатора».
Часто разработчики возмущаются: «Заказчик не хочет оплачивать написание тестов». Я считаю это возмущение беспочвенным. Заставлять заказчика платить за автотесты - это как в ресторане брать плату с гостей за возможность помыть руки перед ужином. Такая возможность важна для заведения - чтобы гость ничем не заразился и не подал на ресторан в суд. С точки зрения создания ПО автотест нужны разработчикам - от тестов зависит качество решения, возможность безболезненного внедрения новых фичей на длинной дистанции, отсутствие багов и хорошее настроение заказчика.
#5. Не надейтесь, что все получится без нормального общения
Несмотря на то, что созвоны стали частью профессионального фольклора айтишников и главным сюжетом для мемов, без регулярных «митингов» ничего не получится. Как понять, что имелось ввиду при постановки задачи, если задача описывается одним приложением? Каким будет ход мысли разработчика, который берется за ее реализацию? На что именно следует обратить внимание QA-специалиста при тестировании? Все это малореально понять без регулярного общения.
Добавлю, что «дейликов» и «викликов» на первом этапе может быть недостаточно. Убедитесь, что люди в команде знают друг друга и не испытывают стеснения друг к другу обращаться с тем или иными вопросами. Обычно модератором качественного общения выступает менеджер проекта. И чем более непредсказуемым будут скиллы технических специалистов при разработке, тем более квалифицированным должен быть главный «бюрократ» проекта.