Николас Френкель -- технолог: готовый с радостью часами дискутировать с вами о преимуществах Java в сравнении со Scala, SQL в сравнении с NoSQL, Google в сравнении с Apple и т.д. на самом деле, это не столь важно. Статистика показывает, что более половины разрабатываемых проектов -- провальные. Николас занимается разработкой программного обеспечения на разных должностях более 10 лет, и отмечает, что технология никогда не была основной причиной ошибок.
За свою карьеру он определил 3 главных источника провалов проекта (не по порядку):
Неумение принимать решения
Как архитектор, Николас старается предусмотреть различные решения, которые более или менее соответствуют требованиям. Каждое имеет свою цену и риск. В ответ ожидается четкое решение со стороны руководства касательно этих альтернатив. Когда начальство уклоняется от обязанности принятия решений, проектам не хватает четкого видения и рано или поздно они обречены на провал. Вероятно, рано.
Несформулированные производственные потребности
Традиционные модели водопадной разработки требуют формальной спецификации, а более современные гибкие модели требуют определения владельца продукта. Однако, в обоих случаях главное, чтобы программист знал, что разрабатывать.
Условием успешного проекта является умение корпоративных пользователей работать над своими потребностями: формулировать их, охарактеризовать и уточнить. Верные признаки будущего провала –- разговоры вроде «у нас нет времени это записать» или «это очевидно». Хотя первое понятно –- у фирмы тоже есть дела, но оба вместе демонстрируют отсутствие заинтересованности и ответственности. Единственным логичным выводом будет отказ конечного пользователя.
Ретроспективное планирование
Проекты должны быть реалистичными. Точнее, людей нужно спросить, за сколько времени они рассчитывают завершить задание, и планирование проекта должно базироваться на этом. Если получается наоборот, будьте готовы к неудаче.
Если планирование не реалистичное, уложиться в сроки нелегко: иногда кажется, что весь мир сговорился остановить тебя. Из-за недостижимости целей давление начнет возрастать, мотивация снижаться, и в какой-то момент руководитель проекта будет вынужден предоставить запасной план: реалистичное планирование.
Итак, вместо поисков лучших технологий, нам следует иногда сосредотачиваться на других вопросах и стараться устранить наиболее вероятные препятствия, даже если они не из нашей сферы интересов.
Николас отмечает, что, как инженер, он был не готов решать эти трудности: они не имеют никакого отношения к технологиям, но только устранив их, мы можем снова сосредоточиться на своем основном деле, создавая качественные программы.
источник
За свою карьеру он определил 3 главных источника провалов проекта (не по порядку):
Неумение принимать решения
Как архитектор, Николас старается предусмотреть различные решения, которые более или менее соответствуют требованиям. Каждое имеет свою цену и риск. В ответ ожидается четкое решение со стороны руководства касательно этих альтернатив. Когда начальство уклоняется от обязанности принятия решений, проектам не хватает четкого видения и рано или поздно они обречены на провал. Вероятно, рано.
Несформулированные производственные потребности
Традиционные модели водопадной разработки требуют формальной спецификации, а более современные гибкие модели требуют определения владельца продукта. Однако, в обоих случаях главное, чтобы программист знал, что разрабатывать.
Условием успешного проекта является умение корпоративных пользователей работать над своими потребностями: формулировать их, охарактеризовать и уточнить. Верные признаки будущего провала –- разговоры вроде «у нас нет времени это записать» или «это очевидно». Хотя первое понятно –- у фирмы тоже есть дела, но оба вместе демонстрируют отсутствие заинтересованности и ответственности. Единственным логичным выводом будет отказ конечного пользователя.
Ретроспективное планирование
Проекты должны быть реалистичными. Точнее, людей нужно спросить, за сколько времени они рассчитывают завершить задание, и планирование проекта должно базироваться на этом. Если получается наоборот, будьте готовы к неудаче.
Если планирование не реалистичное, уложиться в сроки нелегко: иногда кажется, что весь мир сговорился остановить тебя. Из-за недостижимости целей давление начнет возрастать, мотивация снижаться, и в какой-то момент руководитель проекта будет вынужден предоставить запасной план: реалистичное планирование.
Итак, вместо поисков лучших технологий, нам следует иногда сосредотачиваться на других вопросах и стараться устранить наиболее вероятные препятствия, даже если они не из нашей сферы интересов.
Николас отмечает, что, как инженер, он был не готов решать эти трудности: они не имеют никакого отношения к технологиям, но только устранив их, мы можем снова сосредоточиться на своем основном деле, создавая качественные программы.
источник
Комментариев нет:
Отправить комментарий