"Как молоды мы были, как много дров мы нарубили!"

Имею дерзость поделиться опытом разработки приложений, которые приводят к провалу.

Культ собственной глупости, который мы сами и возводим, утопая в иллюзиях и делая ошибку за ошибкой. Опыт не выдуманный, опыт который нелегко вспоминать, а уж тем более делиться. Но раз уж в своем блоге решил быть откровенным, то стоит быть откровенным до конца, обнажая даже неприглядное.

Упоминал уже в предыдущих постах истории, что наша первая попытка разработки системы управления проектами, аналога Jira, закончилась провалом. Из которого вместе с Вами постараемся сделать правильные выводы.

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

И мы решили, как наверно поступают и многие, занять освободившихся разработчиков созданием собственного продукта.

Мы еще только на старте, а уже ПЕРВАЯ ОШИБКА.

Цель (глубокий вдох) - занять разработчиков, а не разработать продукт. Дикость! С такой целью лучше даже не начинать.

Ставьте правильные цели!

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

Это и подвело нас прямиком ко ВТОРОЙ ОШИБКЕ.

Отсутствие горизонта планирования развития проекта, отсутствие гибкости используемого архитектурного подхода разработки.

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

Планируйте развитие своего продукта, не будьте луковым заложником!

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

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

А т.к. документацию мы не вели в силу экономии времени и концентрации на процессе разработки, то оказалось что большинство знаний клиентской части ушло вместе с ведущими клиентскими разработчиками.

Как итог - качество клиентской разработки резко упало.

ОШИБКА ТРЕТЬЯ. Выбор стека технологий не из списка основных для команды, отсутствие тех документации.

Документируйте результаты Вашей работы. Без бумажки...ну вы поняли.

Постоянное переключение разработчиков с проекта на проект не позволяло нарастить их личную вовлеченность и поднять мотивацию. Случалось даже так, что задачу начинал делать один разработчик, а заканчивал уже другой.

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

ОШИБКА ЧЕТВЕРТАЯ. Отсутствие четко формализованных тех. процессов.

Настраивайте процессы взаимодействия внутри команды. Не пускайте разработку на самотёк.

В силу занятости нашего дизайнера коммерческими проектами студии, я решил взять на себя роль ui/ux дизайнера, хотя коммерческой практики в дизайне было крайне мало.

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

Но мне каждая переделка макета стоила титанических усилий. В общем я затягивал с макетами.

ОШИБКА ПЯТАЯ. Если хотите лично участвовать в проекте, а не только руководить процессом - ради бога! Только не замыкайте на себе процессы и не блокируйте работу остальных членов команды. Делегируйте, Вы же руководитель!

Так мы собрали все очевидные ошибки, которые только может допустить юная и еще зеленая компания.

Занавес. Фиаско вышло на поклон.