Как быстро и больно убить проект

В начале хотелось бы представиться с профессиональной стороны: я не являюсь супер-мега гуру проектного менеджмента, но постоянно сталкиваюсь с проблемами и ищу их наиболее выгодное решение. Для этого я использую свой опыт и те размышления, которые возникают во время чтения всевозможной литературы по управлению процессами/проектами/людьми. И конечно же, я прислушиваюсь к мнению окружающих, но только как еще к одному источнику информации. Итак, я — РМ/ScrumMaster, а в недалеком прошлом QA.

А поговорить хочу о том, что мы часто делаем в ИТ, а именно — об «убийстве» проектов. Ниже я привел список шагов по убийству проектов, который, возможно для всех прост и понятен. Для меня важнее почитать ваши комментарии на эту тему после.

Итак, 10 рекомендаций, как быстро и больно убить проект:

1. Нужно как можно меньше общаться друг с другом, не только в рамках компании, но и в команде в целом. Просто берем задачу из списка и делаем ее — без лишних слов. Общение ни к чему доброму не приведет и только увеличит количество проблем и вопросов.

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

3. Оценивать время выполнения проекта или задачи нужно очень оптимистично, и конечно же, вычитать менеджерские 20%. Ведь менеджерам всегда всё нужно как можно скорее. Самая оптимистичная оценка позволит сократить время разработки и поможет вложиться в сроки.

4. Забудьте слова Scrum, XP, Kanban и всё, что связано с процессами. Настоящие профессионалы действуют по наитию и всегда помнят всё, что происходит вокруг и — что самое главное — контролируют это.

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

6. Совершенно ненужным элементом разработки является тестирование. Избавьтесь от него и не забудьте уволить специалистов-куашников. Знать, что с продуктом что-то не так — не нужно: с ним ведь ничего не может приключиться. И, самое главное, мы создаем функционал, а не баги.

7. Не стоит поощрять желание к саморазвитию. Это приведет только к потере времени, денег и нигде больше не пригодиться. Более того, ваша команда получит новые скиллы, попросит повышения оплаты или просто пойдет применять их в другом проекте. Ваше собственное саморазвитие и, тем более, команды — пустая трата ресурсов. Лучше сказать клиенту, что возможна скидка на создание продукта, так как разработчики все еще из прошлого века.

8. Думайте о том, что вы работаете с объектами, которые зарабатывают деньги, а не с людьми — так вам будет проще с ними взаимодействовать и, конечно же, увольнять.

9. Избавьтесь от зон отдыха и не вздумайте поставить настольный теннис или футбол. Это дорого, шумно и только отвлекает всех от выполнения поставленных задач. Люди лучше работают без отдыха и разрядки, а после 18:00 у них полно своего личного времени.

10. Обязательно жестко контролируйте время: как прихода/ухода на рабочее место, так и на выполнение задач. Это привнесет прозрачность в рабочие процессы, даст возможность все предусматривать и контролировать.

А как вы убивайте свои проекты? :)

Похожие статьи:
Каждый год мы увеличиваем количество процессорных ядер, чтобы повысить общую производительность наших систем и улучшить...
2-13 липня в японському місті Тіба відбулася 64-а Міжнародна учнівська олімпіада з математики (International Mathematical Olympiad, IМO),...
Понад пів року ми висвітлюємо, як реагує, допомагає та працює ІТ-індустрія під час війни. У новому випуску...
Кабмін розглядає нову концепцію бронювання, яка залежатиме від сплати податків, про це виданню LIGA.net...
[DOU Hobby — рубрика о нетехнических проектах IT-специалистов: творчество, интересное хобби и другие...
Яндекс.Метрика