Неудачный проект сделать очень просто. Делимся главными проблемами в разработке, которые могут погубить любой проект.
Неудачный проект сделать очень просто. Если вы поищете в интернете тексты о тенденциях разработки, то наверняка найдете бесконечный список статей и информации о быстро развивающихся технологиях и том, как они повлияют на всех нас к 2020 году. Но мало кто пишет о том, почему проекты проваливаются.
Я единственный парень в Crane.ai, который не пишет код, и меня давно мучает эта проблема. Конечно, и не программисты также являются частью проблемы. Сначала в моей статье говорилось о 5 причинах того, почему проекты разработки терпят неудачу. Но, как и следует хорошему заказчику, я полностью сменил спецификации в середине реализации. Теперь это 10 причин, по которым разработка превращается в ничто и наши проекты терпят неудачи.
1. Плохо определенный (или вообще неопределенный) результат
“Мобильное приложение? Мы строим мост, оно ему понадобиться?”
Одной из самых больших проблем, мешающих разработке программного обеспечения, является плохо определенный результат. Без правильного определения того, каким должен быть «конечный продукт», проект гарантированно потерпит неудачу.
Определение результата очень важно. Проект может сменить направление и вам придется попрощаться со всей проделанной работой (вот почему он #1 в моем списке!). Я настоятельно рекомендую составить спецификацию, чтобы лучше определить, как будет выглядеть продукт, что он будет делать и как он это будет делать.
2. Решение не той проблемы
«Мы построили новый деревянный мост, который выглядит намного лучше старого. Машины? Нет, машины по нему ездить не смогут. Все тяжелее птицы сломает это”.
Другая распространенная проблема - это решение не той задачи. Это частично совпадает с плохо определенным результатом, но, в целом, гораздо шире. Несмотря на то, что вы можете правильно определить конечный продукт и правильно решить другие проблемы, которые мы обсуждаемые здесь, если ваш продукт не решает проблему должным образом, вы ничего не добьетесь. Еще один неудачный проект.
Одним из способов решения этой проблемы является инкрементальная реализация. Определите вашу основную задачу, какие шаги можно предпринять для ее решения и возможные решение. Далее, постоянно обновляйте продукт получая обратную связь от ваших пользователей. Постоянно проверяйте их задачи и ваше воплощение. Это позволит убедиться, что проект должным образом отвечает потребностям и является решением основной задачи.
3. Недостаток общения
«Мы построили половину моста, они построили половину туннеля».
От этой проблемы страдают практически все проекты, отрасли и компании - коммуникации. Коммуникация жизненно важна на каждом уровне проекта разработки ПО.
На внутреннем уровне ваши разработчики должны эффективно общаться друг с другом. Это гарантирует создание правильных инструментов и конвейеров, которые согласованы и совместимы. Распространенным решением здесь является разработка предварительных спецификаций для проектирования, API и любых других технических требований, необходимых для вашего проекта. Это жизненно важно для экономии сотен часов времени, которые иначе будут впустую потрачены на рефакторинг и реструктуризацию.
На более высоком уровне также важно правильно общаться с другими командами. Например, маркетинговая команда должна знать, что технологически возможно, прежде чем продавать концепцию.
Неспособность общаться может вызвать проблемы проекта в целом - продукт может отличаться от того, что мы продали, обещали, построили и было необходимо.
4. Отсутствие плана или сроков
“Да ... это будет ... через пару недель? Не уверен, чем мы будем заниматься после этого…”
Независимо от того, соблюдаются ли сроки и планы, важно иметь их. Это каркас вашего проекта. Он даст вам хотя бы приблизительную оценку того, когда и как задачи будут выполнены.
Конечно, хороший план это намного больше. Хороший план или график для больших команд могут служить общей границей, что позволит им быстро и эффективно работать в спринтах. Если реализация функции не удается или требует больше времени, то план/график можно быстро скорректировать, а вслед за ними изменить и бюджет.
5. Отсутствие ответственности
“Фишка дальше не идёт!” - вероятно, Гарри Трумэн.
Когда дерьмо попадает в вентилятор, кто-то должен быть готов со шваброй убрать его. Если какая-либо функция проваливается, должно быть ясно, кто несет ответственность, и какие шаги следует предпринять, чтобы предотвратить это в будущем.
Это звучит по-детски, но в индустрии разработки обычным делом является перекладывание ответственности. Бэкэндеры обвиняют фронтендеров, которые винят отдел продаж, который винит маркетинг, который винит юристов, которые винят руководство… Этот процесс это не только отнимает много времени и губителен для морального состояния компании. Кроме того главный вопрос - «что пошло не так?» - остается открытым и без ответа.
6. Слишком частое изменение целей
«Хорошо, но теперь мост должен работать взлетно-посадочной полосой, иметь еще 10 полос, а как насчет парка посредине?»
Важно отслеживать цели проектов и следить за их своевременным выполнением, иначе вы получите еще один неудачный проект. Вполне возможно, что проект необходимо будет расширить или требования изменятся. Но частые изменения в «конечной цели» могут не только разрушить моральный дух команды, но и сделать невозможным выполнение проекта как такового. Часто изменения не запланированы и требуют большого рефакторинга. Со временем это приводит к большим потерям времени и, в конечном итоге, к провалу проекта.
То, что на первый взгляд может показаться небольшим изменением, в конечном итоге может стать большим проектом.
7. Неадекватная документация и трекинг
«В инструкциях по обезвреживанию этой бомбы говорится, что нужно отключить красный провод, как только отключится питание, но все провода красного цвета, а питание должно было отключиться 10 минут назад!» - Джеймс Бонд в конце карьеры.
Можно следовать гибкой методологии и быстро двигаться вперед, но документация всегда важна. Недокументированный код может привести к многолетнему техническому долгу и может вызвать огромные проблемы в будущем из разряда «что делает эта функция?». Неудачный проект так и будет ковыряться в этих проблемах.
Очень важно документировать продукт. Каждый шаг процесса - от идеи до дизайна и разработки - нужно хорошо документировать, чтобы обеспечить простоту навигации по проекту и возможность трекинга. Хорошая документация может облегчить отслеживание ключевых этапов проекта.
8. Плохо определенные системные требования
«Черт возьми, ты имеешь в виду, что на 5000 людей у нас есть только 5 хлебов и 2 рыбы?!»
Технические требования проекта могут быть трудно измеримы. Но крайне важно, чтобы вы их определили. То, что может показаться небольшим дополнением, вполне способно превратиться в большую проблему, которой нужна дополнительная инфраструктура и переопределение всей системы для реализации поддержки.
9. Плохая подготовка
«У нас все еще есть половина корабля».
Часто проект увлекательный, и в него легко "войти". Однако для этого жизненно важно обеспечить надлежащую подготовку. Необходимо создать спецификации, разработать дизайн-систему, согласовать сроки и выделить ресурсы.
Популярным методом управления этим на техническом уровне является Test Driven Development. Прежде чем писать одну строчку кода для проекта, спланируйте архитектуру и то, что нужно выполнять каждой части. Затем напишите тесты, чтобы понять, что каждый кусок действительно делает то, что предполагалось. Таким образом, у вас будет готовая структура с поставленными целями, и вы можете количественно оценить прогресс в разработке вашего продукта.
10. Нереалистичные ожидания
«Отлично, приложение выглядит прекрасно. Но почему цветовая схема не меняется автоматически в соответствии одеждой пользователя?»
Важно управлять ожиданиями. Часто клиент запрашивает необоснованную, непрактичную или невозможную функцию. Обычной практикой является ограничение количества изменений, которые можно внести в спецификацию. Также необходимо присутствие программиста во время обсуждений. Он сможет определить, является ли функция технологически осуществимой. Неудачный проект пытается реализовать все "хотелки" сразу.
Надеемся, что, в следующий раз вы избежите эти 10 ловушек, а ваш следующий проект постигнет оглушительный успех! А с какими проблемами вы сталкивались в проектах?
Комментарии