, , web design, , , , web , , , , , web site development, , , , -, web-

Статьи: веб дизайн и разработка сайтов / Менеджмент веб проектов, управление программистами / Правила Ашманова
 

Ненормативная лексика руководителя

http://www.ashmanov.com

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

Ссылки по теме:
"Правила Ашманова": часть первая
"Правила Ашманова" - часть вторая: управление проектами

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

  • За проект отвечают Пронькин, Тюлькин и Васькин.

    Комментарий: так не бывает. Шофер у автомобиля должен быть один. Три или пять "ответственных" обязательно развалят проект.

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

    Комментарий: так говорит менеджер, не понимающий сути разработки ПО (которая "не резиновая") и не контролирующий ситуацию в проекте (который скорее всего уже сорван).

    Кстати, это точная цитата "из жизни".

  • Загруженность Петрова по нашему проекту 57%, а Сидорова - 15%.

    Комментарий: обычно подобные дробные значения загруженности используют в системах управления проектами (или просто в Microsoft Excel) для "точного подсчета" ресурсов.

    Я как-то не очень верю в подобные расчеты. Жизнь устроена так, что чаще всего 15% на самом деле равняются 0%, а 57% превращаются в 100% или 120%. Лучше всего, когда под проект выделена полностью занятая в нем рабочая группа, которая изредка дергает другие обслуживающие отделы.

  • Надо, чтобы каждый перед уходом отмечал, сколько он сделал по проекту. Тогда мы будем точно знать состояние дел.

    Комментарий: проверено - не работает. Как минимум, не работает как средство исправления ситуации в неблагополучном проекте. И как средство контроля помогает весьма умеренно. Ситуацию в проекте должен знать и сообщать его руководитель, а не автоматическая система контроля.

  • Программистов нужно штрафовать за срыв сроков, чтобы чувствовали ответственность.

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

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

  • Почему вы всё время требуете новую технику? Неужели нельзя ускорить программу? Между прочим, вас наняли как раз потому, что вы опытный специалист по программированию и должны сэкономить на технике.

    Комментарий: звучит логично, если бы не тот факт, что босс постарается денег на технику не дать в любом случае. Удастся ускорить или нет - техники не будет. Типичный случай попытки не кормить лошадь - а вдруг пообвыкнет? Тоже, между прочим, цитата из реальной жизни.

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

  • Я разослал всем проект/план/ТЗ, но никто не ответил. Что я, за ними гоняться должен? Они же взрослые люди. Какие ко мне претензии?

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

  • Я считаю, каждый должен заниматься своим делом, в своей зоне ответственности. Я не должен делать работу за них.

    Комментарий: это типичная фраза из арсенала так называемой "спихотехники". Внешне звучит совершенно правильно, прямо из западного курса MBA, но по сути означает снятие с себя ответственности за ход проекта в целом и отказ от усилий по коммуникации с другими участниками.

    Точный перевод на русский язык: "я прокукарекал, а там хоть и не рассветай".

  • Состояние проекта - ну чего там писать! Я сейчас всё на словах скажу. Работа ведется, всё нормально.

    Комментарий: постоянное откладывание менеджером проекта рапорта о состоянии дел - самый грозный признак приближающегося или уже наступившего срыва проекта.

  • Да он нормальный руководитель, только вот план никак не напишет.

    Комментарий: основная физиологическая функция менеджера - это планирование своей и чужой работы. Если менеджер никак не напишет план - это не менеджер. Либо он уклоняется от взятия на себя ответственности, либо вообще не способен планировать работу.

  • Да, с проектами и руководством людьми у него не очень. Но вообще польза от него бывает, вот на той неделе написал пару бумаг/провел пару встреч на неплохом уровне.

    Комментарий: здесь явно обсуждается виртуальный сотрудник. Возможно, действительно как-то этого менеджера использовать можно (на побегушках), только его позиция в компании и зарплата предполагают гораздо более внушительные результаты. А порученец на позиции среднего менеджера - не нужен.

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

  • Это ключевой человек. Если он уйдет, всё рухнет.

    Комментарий: такое бывает, но к счастью, довольно редко. Часто после ухода "ключевого" менеджера всё "устаканивается" на удивление быстро - либо потому, что "ключевой человек" уже давно имитировал деятельность, ушел неспроста и рушиться просто нечему, либо потому что его незаменимость просто была преувеличена. Конечно, главный вопрос - как распознать, какой случай имеет место сейчас...

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

  • У нас работают такие творческие люди, что их не загонишь в рамки планов и прочей бюрократии.

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

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

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

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

    Комментарий: боюсь, менеджер тут путает комфортные личные отношения и "командность" подчиненного с практической пользой для компании. Явно имеются признаки виртуальной реальности, когда питье пива с шефом заменяет реальные результаты. Можно прогнозировать, что очередной дружеский разговор ничему не поможет.

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

  • В принципе, к ним есть какие-то нарекания, но вообще что-то там они делают в своем проекте. Надо как-нибудь разобраться, как там дела.

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

  • Давайте соберем всех и наконец всё решим по проекту.

    Комментарий: собрания типа новгородского вече - типичный признак "виртуального", несуществующего проекта. Собираются на них без подготовки, обсуждение идет зигзагами. Большая часть собравшихся не включается в обсуждение или не берет на себя ответственность. Кончаются они чувством раздражения и еще большей неясностью. Эффективные решения в группе 5-10 человек, мало заинтересованных проектом, - не принимаются.

  • Ну послушайте, мы уже потратили на проект кучу денег, давайте уж доведем его до конца...

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

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

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

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

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

    А вот закрыть проект или перезапустить его, честно запланировав нормальный выпуск (и признав срыв сроков), - можно. И это по-мужски.

  • Конечно, можно выпустить проект в срок, но с ошибками. А я считаю, что нужно выпускать, когда получится, но зато качественно.

    Комментарий: характерное предложение руководителя проекта при имеющемся уже срыве сроков, фактически - "отмазка". Безусловно, качественный продут лучше. Но только в том случае, когда срок "качественного" выпуска также точно зафиксирован. В противном случае эта нечаянная любовь к качеству - просто прикрытие срыва проекта и переноса сроков.

  • А куда мы денем руководителя проекта - мы ведь брали его именно под этот проект?

    Комментарий: но ведь вы не брались обеспечивать его семью до конца жизни? Сильный человек найдет свое место в компании или за ее пределами; слабый ей в принципе не нужен. В любом случае это не аргумент для продления агонии проекта.