АКТУАЛЬНЫЕ УПРАВЛЕНЧЕСКИЕ РЕШЕНИЯ | СЛОВАРЬ НЕНОРМАТИВНОЙ ЛЕКСИКИ РУКОВОДИТЕЛЯ ПО И. АШМАНОВУ (ПРОЕКТНАЯ ДЕЯТЕЛЬНОСТЬ)





СЛОВАРЬ НЕНОРМАТИВНОЙ ЛЕКСИКИ РУКОВОДИТЕЛЯ (ПРОЕКТНАЯ ДЕЯТЕЛЬНОСТЬ) 


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Игорь Ашманов © "Ашманов и Партнеры", Источник: https://www.ashmanov.com/education/articles/slovar-nenormativnoy-leksiki-rukovoditelya/


СЛОВАРЬ НЕНОРМАТИВНОЙ ЛЕКСИКИ ПРОГРАММИСТА ПО И. АШМАНОВУ - http://www.actually.pro/0771.html






НОВОСТИ ПОРТАЛА «АКТУАЛЬНЫЕ УПРАВЛЕНЧЕСКИЕ ЗНАНИЯ»
«Повышение вашей управленческой компетенции. Потому что разбираться в предметах – это знать, как ими управлять и чего от них ждать.»