Словарь ненормативной лексики руководителя

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

Организовать проект - сейчас сделаем!

• За проект отвечают Пронькин, Тюлькин и Васькин.
  
  Комментарий: так не бывает. Шофер у автомобиля должен быть один. Три или пять "ответственных" обязательно развалят проект.
  
  
• Что-то вы много работы насчитали. Выдумываете сложности. Нужно просто напрячься, недельку посидеть ночами и всё сделать! С программистами всегда так. Ты поговори там с ребятами.
  
  Комментарий: так говорит менеджер, не понимающий сути разработки ПО (которая "не резиновая") и не контролирующий ситуацию в проекте (который скорее всего уже сорван).
  
  Кстати, это точная цитата "из жизни".
  
  
• Загруженность Петрова по нашему проекту 57%, а Сидорова - 15%.
  
  Комментарий: обычно подобные дробные значения загруженности используют в системах управления проектами (или просто в Microsoft Excel) для "точного подсчета" ресурсов.
  
  Я как-то не очень верю в подобные расчеты. Жизнь устроена так, что чаще всего 15% на самом деле равняются 0%, а 57% превращаются в 100% или 120%. Лучше всего, когда под проект выделена полностью занятая в нем рабочая группа, которая изредка дергает другие обслуживающие отделы.
  
  
• Надо, чтобы каждый перед уходом отмечал, сколько он сделал по проекту. Тогда мы будем точно знать состояние дел.
  
  Комментарий: проверено - не работает. Как минимум, не работает как средство исправления ситуации в неблагополучном проекте. И как средство контроля помогает весьма умеренно. Ситуацию в проекте должен знать и сообщать его руководитель, а не автоматическая система контроля.
  
  
• Программистов нужно штрафовать за срыв сроков, чтобы чувствовали ответственность.
  
  Комментарий: не поможет, они просто разбегутся. Проблемы со сроками возникают от плохого управления, так что штрафовать нужно менеджеров.
  
  Кроме того, всегда соблюдать все сроки в разработке ПО практически нельзя. Вместо этого нужно иметь разумную систему диагностирования проблем на ранних этапах и процедуру переноса сроков.
  
  
• Почему вы всё время требуете новую технику? Неужели нельзя ускорить программу? Между прочим, вас наняли как раз потому, что вы опытный специалист по программированию и должны сэкономить на технике.
  
  Комментарий: звучит логично, если бы не тот факт, что босс постарается денег на технику не дать в любом случае. Удастся ускорить или нет - техники не будет. Типичный случай попытки не кормить лошадь - а вдруг пообвыкнет? Тоже, между прочим, цитата из реальной жизни.
  
  

Что-то вялый у нас руководитель проекта...

• Я разослал всем проект/план/ТЗ, но никто не ответил. Что я, за ними гоняться должен? Они же взрослые люди. Какие ко мне претензии?
  
  Комментарий: в общем, должен гоняться, конечно. Иначе проект закиснет. От руководителя требуется решать любые проблемы проекта, в том числе перебарывать отсутствие интереса к проекту у смежников и рабочей группы.
  
  
• Я считаю, каждый должен заниматься своим делом, в своей зоне ответственности. Я не должен делать работу за них.
  
  Комментарий: это типичная фраза из арсенала так называемой "спихотехники". Внешне звучит совершенно правильно, прямо из западного курса MBA, но по сути означает снятие с себя ответственности за ход проекта в целом и отказ от усилий по коммуникации с другими участниками.
  
  Точный перевод на русский язык: "я прокукарекал, а там хоть и не рассветай".
  
  
• Состояние проекта - ну чего там писать! Я сейчас всё на словах скажу. Работа ведется, всё нормально.
  
  Комментарий: постоянное откладывание менеджером проекта рапорта о состоянии дел - самый грозный признак приближающегося или уже наступившего срыва проекта.
  
  
• Да он нормальный руководитель, только вот план никак не напишет.
  
  Комментарий: основная физиологическая функция менеджера - это планирование своей и чужой работы. Если менеджер никак не напишет план - это не менеджер. Либо он уклоняется от взятия на себя ответственности, либо вообще не способен планировать работу.
  
  
• Да, с проектами и руководством людьми у него не очень. Но вообще польза от него бывает, вот на той неделе написал пару бумаг/провел пару встреч на неплохом уровне.
  
  Комментарий: здесь явно обсуждается виртуальный сотрудник. Возможно, действительно как-то этого менеджера использовать можно (на побегушках), только его позиция в компании и зарплата предполагают гораздо более внушительные результаты. А порученец на позиции среднего менеджера - не нужен.
  
  

Кадры решают всё?

• Это ключевой человек. Если он уйдет, всё рухнет.
  
  Комментарий: такое бывает, но к счастью, довольно редко. Часто после ухода "ключевого" менеджера всё "устаканивается" на удивление быстро - либо потому, что "ключевой человек" уже давно имитировал деятельность, ушел неспроста и рушиться просто нечему, либо потому что его незаменимость просто была преувеличена. Конечно, главный вопрос - как распознать, какой случай имеет место сейчас...
  
  Период вступления в управление проектом нового менеджера подобен небольшому землетрясению в проекте, но главное - чтобы новый руководитель был действительно "правильный".
  
  
• У нас работают такие творческие люди, что их не загонишь в рамки планов и прочей бюрократии.
  
  Комментарий: наиболее типовая мантра в программистских компаниях. Так обычно успокаивает себя руководитель, не сумевший навести порядок и наладить промышленное производство ПО.
  
  
• Нам нужны люди, но такие своеобразные/творческие, что кадровые агентства здесь не помогут.
  
  Комментарий: напротив, опыт показывает, что кадровые агентства как раз помогают - быстро находят очень квалифицированных людей. Правда, это дорого. В противном же случае "творческих людей" берут по знакомству и потом никто не решается твердо спросить их про плоды их творчества. К тому же круг знакомых как источник кадров быстро иссякает.
  
  
• Да он хороший, командный парень. Ну, работу, конечно провалил, да я его вообще за это пинаю каждый день. В пятницу мы с ним в боулинге выпьем пива и серьезно поговорим.
  
  Комментарий: боюсь, менеджер тут путает комфортные личные отношения и "командность" подчиненного с практической пользой для компании. Явно имеются признаки виртуальной реальности, когда питье пива с шефом заменяет реальные результаты. Можно прогнозировать, что очередной дружеский разговор ничему не поможет.
  
  

Отчего всё не так? Продолжать или бросить?

• В принципе, к ним есть какие-то нарекания, но вообще что-то там они делают в своем проекте. Надо как-нибудь разобраться, как там дела.
  
  Комментарий: очень похоже на теплый "карман" виртуального существования. Боюсь, сил разобраться у босса не будет еще долго.
  
  
• Давайте соберем всех и наконец всё решим по проекту.
  
  Комментарий: собрания типа новгородского вече - типичный признак "виртуального", несуществующего проекта. Собираются на них без подготовки, обсуждение идет зигзагами. Большая часть собравшихся не включается в обсуждение или не берет на себя ответственность. Кончаются они чувством раздражения и еще большей неясностью. Эффективные решения в группе 5-10 человек, мало заинтересованных проектом, - не принимаются.
  
  
• Ну послушайте, мы уже потратили на проект кучу денег, давайте уж доведем его до конца...
  
  Комментарий: это плохая мотивировка. Доведение до конца ненужного или неудачного проекта обычно съедает еще больше денег, сопровождается скандалами и увольнениями.
  
  
• Как же закрыть проект, ведь обещаний в прессе, начальству, партнерам мы уже дали вон сколько... Я не готов принять такое решение.
  
  Комментарий: подобная нерешительность руководителя - путь к долгой и мучительной агонии проекта и еще большей потере лица в итоге. Впрочем, если тянуть достаточно долго, даже партнеры и журналисты могут забыть об обещанном выпуске проекта.
  
  
• Проект уже навяз на зубах, мы всем обещали, пресса ждет, давайте выпускать как есть.
  
  Комментарий: выглядит как волевое решение. Руководитель доволен, что наконец поступил по-мужски (вариант: как настоящий бизнесмен). Однако это имитация решения: если проект в плохом состоянии, выпускать его категорически нельзя - выпуск дрянного продукта будет виден всем, будет испорчена репутация многих участников проекта и самой компании, на следующий же день среди высшего менеджмента начнутся разборки и т. п.
  
  А вот закрыть проект или перезапустить его, честно запланировав нормальный выпуск (и признав срыв сроков), - можно. И это по-мужски.
  
  
• Конечно, можно выпустить проект в срок, но с ошибками. А я считаю, что нужно выпускать, когда получится, но зато качественно.
  
  Комментарий: характерное предложение руководителя проекта при имеющемся уже срыве сроков, фактически - "отмазка". Безусловно, качественный продут лучше. Но только в том случае, когда срок "качественного" выпуска также точно зафиксирован. В противном случае эта нечаянная любовь к качеству - просто прикрытие срыва проекта и переноса сроков.
  
  
• А куда мы денем руководителя проекта - мы ведь брали его именно под этот проект?
  
  Комментарий: но ведь вы не брались обеспечивать его семью до конца жизни? Сильный человек найдет свое место в компании или за ее пределами; слабый ей в принципе не нужен. В любом случае это не аргумент для продления агонии проекта.