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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Похожие статьи:
OBRIO запускає стипендіальну програму для студентів факультету інформатики та обчислювальної техніки КПІ ім. Ігоря Сікорського. Троє...
SoftServe запускає хакатон AgentForge, де учасники розроблятимуть рішення на базі Agentic AI. Призовий фонд хакатону становить $10 000. Про...
Естонські фахівці з паспортних даних розробили спеціальну карту з розташуванням адрес прописки російських окупантів,...
Хочу поделиться своими знаниями по прототипированию и показать, как с помощью прототипов улучшить качество вашего...
Будь-який розробник, який працював з iOS BLE, знає, що насправді не все так чудово, як описує документація. Сьогодні...
Яндекс.Метрика