Главная ошибка проджект менеджера или думайте хорошо

Хорошо и много думайте, прежде чем согласиться на проект. Отказывайтесь, если вам не оставляют свободы манёвра. Или хотя бы отдавайте себе отчёт в своих возможностях, дабы избежать разочарования.

К чему это я? А вот прислали картинку (ещё 13го сентября) и навеяла она мысли… а сегодня (о блин, уже вчера!) пришёл проект от сейлов с офигенно понятным скоупом, и я про неё вспомнил. Когда этот пост задумывался, причина была более веской лично для меня, сейчас уже нет - я проекты пока не веду. Но написать, чувствую, всё равно стоит - может _того_ менеджера успокою :) ну типа присказка закончилась, началась сказка…

Наверное самая распространённая ошибка руководящего состава - искренне верить, что из говна можно вылепить конфету. Ошибка не в том, что конфету нельзя вылепить… ошибка в том, что нельзя надеяться при этом, что конфета будет вкусная.

Read the rest of this entry »

“Хорошие шутки” в жизни разработчиков

В пятницу подошёл ко мне Иван Ткач, чтобы обсудить предстоящую ему лекцию в ХАИ по “введению в специальность”. Встал вопрос, как показать наиболее важные проблемы нашей отрасли людям, которые ещё ничего вообще не знают… После недолгого обсуждения решили, что самой важной проблемой является несоответствие реализации ожиданиям клиента, про что я уже писал.

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

Read the rest of this entry »

The importance of being on the same line…

Это будет (или есть) очередная заметка из раздела “ошибки”. Катализатором заметки стал анекдот, который будет чуть ниже, а главная мысль скажу прямо сейчас: если вы что-то подразумеваете, то важно отдавать себе отчёт в том, что “подразумевать” не означает “значить”.

Известная картинка про реализацию проектовЭто верно и в обычной жизни, но в нашей отрасли особенно заметно. Все наверняка помнят поучительную картинку на эту тему. Если её детально рассмотреть, то легко обнаруживается, что самый пострадавший в этой ситуации (ну если не брать в расчёт штрафы, суды и братков с битами) клиент:

  • на модификации системы он потерял кучу времени и денег;
  • в итоге новая фича не юзабельна (кататься невозможно);
  • модифицированная система нестабильна и расширению не подлежит;

Кто тут больше виноват? Клиент ли должен был тщательнее описывать свои требования, аналитик ли должен был тщательнее уточнять требования клиента?

Read the rest of this entry »