1. Слишком мало человек в команде

Когда слишком маленькая команда пытается осуществить слишком многое, получается вполне предсказуемый результат. Некоторые менеджеры считают, что чтобы выжать максимум из команды, работающей по agile, между спринтами нельзя допускать перерывов или отдыха, никаких пауз для рефлексии или разбора ошибок и успехов. Даже ретроспективные обсуждения они назначают на начало следующего спринта, стремясь превратить традиционные «короткие дистанции» в марафонские.

Рассчитать оптимальное количество разработчиков непросто, и даже если это сделано правильно, всегда могут возникнуть непредвиденные обстоятельства. Причина здесь не в плохом менеджменте, но если объём работы удвоился, а в команде оказалось недостаточно человек, проект может быть обречён.

2. В команде слишком много человек

Перебор сотрудников вредит проекту не меньше, чем их нехватка. Те же сетевые эффекты, которые лежат в основе различных платформ социального общения, могут стать губительными для программного проекта. Чем больше людей в команде, тем дольше придётся налаживать работу между ними, и проводить больше совещаний, отнимающих время, которое должно посвящаться написанию кода.

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

3. Изменение ключевого функционала

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

4. Выбор неправильной технологии для реализации функций

Даже если тщательно продумать функционал проекта, можно ошибиться с подбором подходящей технологии для его выполнения. Например, базы данных по возможности создаются максимально гибкими и универсальными, но они ограничены своей архитектурой. Если попытаться использовать их для вещей, для которых они не предназначены, проект постепенно зайдёт в тупик. Кто-то использует NoSQL только потому, что они стали модными, но в итоге оказывается, что команде нужны ACID-транзакции, которые выбранная БД просто не поддерживает.

5. Неправильно расставленные приоритеты

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

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

Разумное планирование — это не просто перечень задач. Менеджеры с комплексным видением проекта должны учитывать и цели проекта, и необходимые для их достижения затраты.

6. Изменение потребностей рынка

Эта ошибка происходит не по вине разработчиков. Например, программисты решили создать приложение для популярного справочника, который продавался как горячие пирожки ещё задолго до появления интернета. Его интерактивная версия позволила бы пользователям искать и сортировать данные. Готовая программа включала всё, что и книга, при этом не занимала место и была проста и удобна в применении, но оказалась никем не востребована, даже за низкую цену: у рынка просто исчезла потребность в этих данных. Появилось достаточно иных ресурсов, и пользователям было ненужно приложение, возможности которого ничем не отличались от множества идентичных новостных сайтов.

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

7. Неправильные архитектурные решения

В одном проекте стояла задача отредактировать число в строке базы данных. После завершения регистрации пользователем программисты должны были внести номер его ID в сортировку по последнему добавлению. Выглядит довольно просто, но система имела архитектурный стиль микросервисов, который не позволял написать лишь одну строчку кода, чтобы база данных обновила нужную колонку. Программисты решили создать вызов нового микросервиса в добавок к уже существующим, но даже здесь они столкнулись с проблемой, потому что для этого нужно было делать вызов ещё одного микросервиса и так далее.

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

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

8. Расхождения во взглядах в команде

По мере роста проекта в нём появляются всё новые уровни и начинают участвовать новые команды, которые могут начать объединяться и бороться за первенство и ресурсы. Причина разногласий сводится к избранной технологии. Иногда технические стандарты или кодовые базы реализуют практически одну и ту же задачу, но разными способами. Например, XML и JSON: хотя приверженцы каждого формата возразят и начнут описывать их несравнимые преимущества, если одна часть команды предпочитает одну технологию, а вторая с ней в корне не согласна, коллектив могут разрушить постоянные противоречия.

Зачастую программисты разбивают приложения на несколько меньших служб и API, которыми будут руководить разные, не ладящие между собой группы. Если одна использует JSON, а вторая — XML, команде придётся или применять обе технологии, или заставить одну из них изменить выбор.

9. Выбор технологии, которая не готова к применению

Программистам нравится пробовать новые инструменты и фреймворки. Им хочется верить, что новый подход устранит все ограничения предыдущих версий, что новые абстракции и методы объединят, расширят и упростят всё, что можно делать с кодом.

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

Такого рода ситуации могут обречь проект на провал. Команды прибегают к новой технологии, ожидая, что она решит многие серьёзные проблемы, и часто они в этом правы. Но в процессе (зачастую — когда команда выходит на финишную прямую) может выявиться, что огромная часть новой технологии отсутствует, и об этом может быть не упомянуто в документации.

10. Выбор устаревшей технологии

Старые технологии хороши тем, что проверены годами и более надёжны, что может оказаться даже ценнее, чем наличие полного функционала. Но это не значит, что старые технологии идеальны; иногда может не хватать функций, которые будут жизненно необходимы для работы программного продукта после релиза. Кроме того, выбрав старые технологии, команда теряет шанс воспользоваться будущими возможностями, которые открывают нововведения. Постоянно появляются свежие идеи, протоколы, форматы файлов, которые команда, выбравшая устаревшие технологии, не сможет опробовать или внедрить, когда в этом возникнет острая необходимость.

11. Невыполнимые сроки

Эксперты советуют всегда удваивать оценочное время на реализацию проектов. Однако со сроками может быть не всё так просто: выход многих проектов на рынок приурочен к определённому сезону или мероприятию. В случае, когда назначенное время прошло, а релиз так и не состоялся, проект признаётся неудачным, даже если код почти идеально отлажен. Дедлайны помогают команде собраться и сосредоточиться, но также могут давать повод для нереалистичных ожиданий.

12. Непредвиденная конкуренция

Хороший менеджер всегда исследует конкурентов, прежде чем команда начнёт работать над продуктом для конкретного рынка, но внезапное появление новых соперников предсказать нельзя. Если они дублируют функционал продукта, придётся пересмотреть пункты об изменении ключевых функций и расстановке приоритетов.

13. Спешка

Многие проекты рождаются, когда у человека или команды появляется идея что-то усовершенствовать. Единственное, что они не всегда понимают, — чтобы подготовить техническое задание, смоделировать потоки данных или придумать пользовательский интерфейс, иногда нужно в разы больше времени, чем для написания кода. Прототипы, логическая структура данных, пользовательские истории не появляются сами по себе и тоже требуют усилий. Хотя для многих разработка проекта — всего лишь написание кода к возникшей идее.

14. Заблуждение о всемогуществе ПО

Некоторые люди ошибочно верят, что программы могут изменить мир к лучшему. Многие были уверены, что социальные сети объединят человечество, но они скорее привлекли ещё больше внимания к и без того очевидным противоречиям. Многие программные проекты начинаются с наивных презентаций, авторы которых обещают и перевернуть жизнь в указанном уголке планеты. Когда выполнить задуманное не удаётся, они начинают злиться и недоумевать. Проект может скомпилироваться, пройти тестирование, выйти на рынок и получить хвалебные отзывы, но так и не воплотить иллюзии создателей. Просто потому, что это невозможно.