воскресенье, 8 апреля 2012 г.

Вредные советы руководителю проектов

Хотите выпускать продукт низкого качества, постоянно проваливая при этом сроки? Хотите разорванных контрактов и разъярённых заказчиков? Хотите, чтобы вас ненавидела ваша команда? Тогда этот пост для вас!

План и сроки

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

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

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

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

Чем чаще вы задерживаете команду на ночь, тем больше она успеет сделать. Оптимальное рабочее время – 100 часов в неделю. Если кого-то это не устраивает – увольте его. Остальным будет страшно потерять работу, и они не будут возмущаться.

Управление рисками

Управление рисками проекта – пустая трата времени. Бессмысленно заниматься анализом проблем, которые могут и не появиться. 

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

От всех рисков можно избавиться, умножив бюджет проекта на пять.

Мотивация и отношения в команде

Мотивация сотрудников – занятие никчёмное и бессмысленное. Вы платите сотрудникам деньги, зачем придумывать что-то ещё?

Самое простое решение любой проблемы - уволить программиста. Не тратьте ваше ценное время на выяснение причин и мотивов его «плохого поведения». Программисты - обычный взаимозаменяемый ресурс.

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

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

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

Запомните: за любую оплошность программистов надо штрафовать. Они работают у вас за зарплату, поэтому уменьшение ее заставит их работать лучше, чтобы не допустить такого в будущем. Кстати, поощрять можно тоже только премиями. Очевидно, что любого наёмного сотрудника интересуют только деньги.

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

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

Команда

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

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

Обо всех неудачах и провалах ваших подчиненных надо немедленно докладывать начальнику. Пусть он знает, что виноваты в провале не вы, а программисты.

Начальство и бизнес

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

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

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

Отношение с заказчиком

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

Разговор с заказчиком - бессмысленная потеря времени. Всё, что надо, он и так написал в ТЗ.

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

7 комментариев:

  1. Еще бы добавил.

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

    Новичку достаточно дать прочитать умную книжку, как он сразу всему научится.

    Не заниматься организацией производственного процесса и нанимать в команду только программистов. Пусть самоорганизуются.

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

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

    Не допускать распределения обязанностей среди программистов. Они должны быть универсальны и взаимозаменяемы.

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

    Если заказчика не волнует качество архитектуры и кода, то программистов это тоже волновать не должно.

    Чтобы не тратить время на тесты, нужно писать код без ошибок.

    ОтветитьУдалить
    Ответы
    1. Точно! Кстати, некоторые из предложений уже есть во второй части. Не стал их сюда добавлять и загромождать пост ;)

      Удалить
    2. В дополнение.

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

      Удалить
    3. Алексей, браво! :) Кратко и емко!

      Удалить
    4. Спасибо за лестный отзыв. Кратко и емко - это мой девиз. :)

      Удалить
  2. "Чем выше квалификация программиста, тем больше ему хочется работать с некачественным кодом." ЭЭЭ?

    ОтветитьУдалить
    Ответы
    1. Хм... А всё остальное не "эээ"? :) Очень хорошее, между прочим, дополнение ко всем тем "советам" из статьи.

      Удалить