Повод для увольнения и отличный урок для меня

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

Первоначально на проект было выделено 9600 часов по фиксированной цене, и, хотя это казалось большим количеством часов, никто из моей команды не оценил их. Это была первая большая ошибка - принять на себя ответственность за что-то без предварительного анализа.

Но было еще много проблем. В этой статье я объясню, как проект может быстро попасть в ад из-за того, что вначале казалось небольшими проблемами.

1. Плохое общение

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

Мы начали тратить часы впустую, пытаясь двигаться вперед, не имея четкой цели, и выполняя задачи, которые оказались «не совсем» тем, что они хотели, когда мы их им показали.

Но всегда чему-то учишься. В этом случае я понял, что необходимо иметь плавное и прямое общение со всеми вовлеченными сторонами.

2. Цели не были ясны

Обычно не все ясно в начале проекта, но то, что должно быть ясно с самого начала, - это цель разработки. Какова цель того, что мы собираемся делать, кто будет этим пользоваться?

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

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

3. Где были заинтересованные стороны?

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

4. В команду были переданы неподготовленные люди.

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

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

5. Участвуйте в других «небольших» проектах.

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

6. Я не знал, как сказать НЕТ.

В то время я очень лично относился к любому проекту, и для меня было жизненно важно завершить что-либо любой ценой. Думаю, я боялся сказать начальству «нет», что было моей большой ошибкой.

Я хорошо усвоил урок. Теперь, если я вижу, что что-то невозможно сделать или что нужно больше часов и больше предыдущей работы, я встаю и проясняю это. Если они хотят идти вперед, не принимая этого во внимание, ответственность не будет на мне. К счастью, я понял, что сказать «нет» - это неплохо, и что это спасает компанию и избавляет вас от многих неприятностей.

7. Заниженные сроки

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

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

8. Упускать из виду детали.

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

9. Работайте более 10 часов каждый день и по выходным.

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

Если мои начальники что-то предпримут, не посоветовавшись с технической командой, ответственность ложится на них.

10. Я принимаю все на свой счет.

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

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

Улыбка!

11. Ярлыки бесполезны

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

12. Порядок имеет основополагающее значение.

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

13. Мы используем технологии, которые не очень хорошо знали.

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

14. Я неправильно расставил приоритеты

Первые недели мы терялись, занимаясь не самыми важными вещами, и мы не расставляли приоритеты в том, что я считаю сегодня важным:

1. Знайте цель продукта, который нужно разработать - ›Определите заинтересованные стороны -› Определите задачи, которые нужно создать вместе с заинтересованными сторонами и командой - ›Определите начальный минимум для разработки, которому можно научить за 2 недели -› Разработайте начальный минимум и поставьте это в производстве - ›Сделайте демо.

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

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

Выученные уроки

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

  • Я научился говорить НЕТ и не работать больше часов, чем отведено моему рабочему дню. Одно дело - иногда работать больше часов, чтобы закончить что-то (несколько дней), но совсем другое - сделать это привычкой.
  • Я научился ничего не делать и не выделять час на проект, пока я не выясню, кто мои заинтересованные стороны, и пока у меня не появятся быстрые и эффективные средства связи.
  • Важно планировать с самого начала, и важны мелкие детали.
    Не пренебрегайте передовым опытом. Нет никаких ярлыков.
  • Необходимо вовремя принимать решения и не ждать, пока все решится само собой, думая, что это сделает кто-то другой.
  • Если вы за что-то отвечаете, докажите это. Не думайте, что остальная часть команды или ваше начальство осведомлены о ситуации.
  • Самое главное для успеха проекта - это первые недели, когда все решается и устанавливается.
  • Поместите все в производственную среду как можно скорее и автоматизируйте развертывание с самого начала. Вы спасаете себя от осознания многих вещей слишком поздно.
  • Старайтесь, чтобы все было как можно более чистым: открыто мало вкладок, мало приложений, а почта всегда чиста в конце дня. И это, хотя это кажется глупым, имеет значение. Опрятная рабочая среда - это основа.
  • В большом проекте с большой степенью неопределенности рекомендуется использовать хорошо известные и хорошо зарекомендовавшие себя технологии. Использование нового фреймворка или языка сопряжено с определенными рисками, например, с кривой обучения, отсутствием большого сообщества или несовместимостью, о которой не известно, поэтому лучше поэкспериментировать с небольшими проектами с низким уровнем риска.
  • Очень помогает улыбка и спокойствие.