|
 Автор: Игорь Ашманов, управляющий партнер и генеральный директор компании «Ашманов и Партнеры»
Этот небольшой словарик является иллюстрацией к «Правилам-2». Здесь собраны типовые высказывания руководителей и/или хозяев компании, которые при настойчивом их повторении приводят к трудностям в управлении проектом и персоналом.
Артем Попов. © «Ашманов и Партнеры» Организовать проект — сейчас сделаем! - За проект отвечают Пронькин, Тюлькин и Васькин.
Комментарий: так не бывает. Шофер у автомобиля должен быть один. Три или пять «ответственных» обязательно развалят проект. - Что-то вы много работы насчитали. Выдумываете сложности. Нужно просто напрячься, недельку посидеть ночами и всё сделать! С программистами всегда так. Ты поговори там с ребятами.
Комментарий: так говорит менеджер, не понимающий сути разработки ПО (которая «не резиновая») и не контролирующий ситуацию в проекте (который скорее всего уже сорван).
Кстати, это точная цитата «из жизни». - Загруженность Петрова по нашему проекту 57%, а Сидорова — 15%.
Комментарий: обычно подобные дробные значения загруженности используют в системах управления проектами (или просто в Microsoft Excel) для «точного подсчета» ресурсов.
Я как-то не очень верю в подобные расчеты. Жизнь устроена так, что чаще всего 15% на самом деле равняются 0%, а 57% превращаются в 100% или 120%. Лучше всего, когда под проект выделена полностью занятая в нем рабочая группа, которая изредка дергает другие обслуживающие отделы. - Надо, чтобы каждый перед уходом отмечал, сколько он сделал по проекту. Тогда мы будем точно знать состояние дел.
Комментарий: проверено — не работает. Как минимум, не работает как средство исправления ситуации в неблагополучном проекте. И как средство контроля помогает весьма умеренно. Ситуацию в проекте должен знать и сообщать его руководитель, а не автоматическая система контроля. - Программистов нужно штрафовать за срыв сроков, чтобы чувствовали ответственность.
Комментарий: не поможет, они просто разбегутся. Проблемы со сроками возникают от плохого управления, так что штрафовать нужно менеджеров.
Кроме того, всегда соблюдать все сроки в разработке ПО практически нельзя. Вместо этого нужно иметь разумную систему диагностирования проблем на ранних этапах и процедуру переноса сроков. - Почему вы всё время требуете новую технику? Неужели нельзя ускорить программу? Между прочим, вас наняли как раз потому, что вы опытный специалист по программированию и должны сэкономить на технике.
Комментарий: звучит логично, если бы не тот факт, что босс постарается денег на технику не дать в любом случае. Удастся ускорить или нет — техники не будет. Типичный случай попытки не кормить лошадь — а вдруг пообвыкнет? Тоже, между прочим, цитата из реальной жизни.
Что-то вялый у нас руководитель проекта... - Я разослал всем проект/план/ТЗ, но никто не ответил. Что я, за ними гоняться должен? Они же взрослые люди. Какие ко мне претензии?
Комментарий: в общем, должен гоняться, конечно. Иначе проект закиснет. От руководителя требуется решать любые проблемы проекта, в том числе перебарывать отсутствие интереса к проекту у смежников и рабочей группы. - Я считаю, каждый должен заниматься своим делом, в своей зоне ответственности. Я не должен делать работу за них.
Комментарий: это типичная фраза из арсенала так называемой «спихотехники». Внешне звучит совершенно правильно, прямо из западного курса MBA, но по сути означает снятие с себя ответственности за ход проекта в целом и отказ от усилий по коммуникации с другими участниками.
Точный перевод на русский язык: «я прокукарекал, а там хоть и не рассветай». - Состояние проекта — ну чего там писать! Я сейчас всё на словах скажу. Работа ведется, всё нормально.
Комментарий: постоянное откладывание менеджером проекта рапорта о состоянии дел — самый грозный признак приближающегося или уже наступившего срыва проекта. - Да он нормальный руководитель, только вот план никак не напишет.
Комментарий: основная физиологическая функция менеджера — это планирование своей и чужой работы. Если менеджер никак не напишет план - это не менеджер. Либо он уклоняется от взятия на себя ответственности, либо вообще не способен планировать работу. - Да, с проектами и руководством людьми у него не очень. Но вообще польза от него бывает, вот на той неделе написал пару бумаг/провел пару встреч на неплохом уровне.
Комментарий: здесь явно обсуждается виртуальный сотрудник. Возможно, действительно как-то этого менеджера использовать можно (на побегушках), только его позиция в компании и зарплата предполагают гораздо более внушительные результаты. А порученец на позиции среднего менеджера — не нужен.
Кадры решают всё? - Это ключевой человек. Если он уйдет, всё рухнет.
Комментарий: такое бывает, но к счастью, довольно редко. Часто после ухода «ключевого» менеджера всё «устаканивается» на удивление быстро — либо потому, что «ключевой человек» уже давно имитировал деятельность, ушел неспроста и рушиться просто нечему, либо потому что его незаменимость просто была преувеличена. Конечно, главный вопрос — как распознать, какой случай имеет место сейчас...
Период вступления в управление проектом нового менеджера подобен небольшому землетрясению в проекте, но главное — чтобы новый руководитель был действительно «правильный». - У нас работают такие творческие люди, что их не загонишь в рамки планов и прочей бюрократии.
Комментарий: наиболее типовая мантра в программистских компаниях. Так обычно успокаивает себя руководитель, не сумевший навести порядок и наладить промышленное производство ПО. - Нам нужны люди, но такие своеобразные/творческие, что кадровые агентства здесь не помогут.
Комментарий: напротив, опыт показывает, что кадровые агентства как раз помогают — быстро находят очень квалифицированных людей. Правда, это дорого. В противном же случае «творческих людей» берут по знакомству и потом никто не решается твердо спросить их про плоды их творчества. К тому же круг знакомых как источник кадров быстро иссякает. - Да он хороший, командный парень. Ну, работу, конечно провалил, да я его вообще за это пинаю каждый день. В пятницу мы с ним в боулинге выпьем пива и серьезно поговорим.
Комментарий: боюсь, менеджер тут путает комфортные личные отношения и «командность» подчиненного с практической пользой для компании. Явно имеются признаки виртуальной реальности, когда питье пива с шефом заменяет реальные результаты. Можно прогнозировать, что очередной дружеский разговор ничему не поможет.
Отчего всё не так? Продолжать или бросить? - В принципе, к ним есть какие-то нарекания, но вообще что-то там они делают в своем проекте. Надо как-нибудь разобраться, как там дела.
Комментарий: очень похоже на теплый «карман» виртуального существования. Боюсь, сил разобраться у босса не будет еще долго. - Давайте соберем всех и наконец всё решим по проекту.
Комментарий: собрания типа новгородского вече — типичный признак «виртуального», несуществующего проекта. Собираются на них без подготовки, обсуждение идет зигзагами. Большая часть собравшихся не включается в обсуждение или не берет на себя ответственность. Кончаются они чувством раздражения и еще большей неясностью. Эффективные решения в группе 5-10 человек, мало заинтересованных проектом, - не принимаются. - Ну послушайте, мы уже потратили на проект кучу денег, давайте уж доведем его до конца...
Комментарий: это плохая мотивировка. Доведение до конца ненужного или неудачного проекта обычно съедает еще больше денег, сопровождается скандалами и увольнениями. - Как же закрыть проект, ведь обещаний в прессе, начальству, партнерам мы уже дали вон сколько... Я не готов принять такое решение.
Комментарий: подобная нерешительность руководителя — путь к долгой и мучительной агонии проекта и еще большей потере лица в итоге. Впрочем, если тянуть достаточно долго, даже партнеры и журналисты могут забыть об обещанном выпуске проекта. - Проект уже навяз на зубах, мы всем обещали, пресса ждет, давайте выпускать как есть.
Комментарий: выглядит как волевое решение. Руководитель доволен, что наконец поступил по-мужски (вариант: как настоящий бизнесмен). Однако это имитация решения: если проект в плохом состоянии, выпускать его категорически нельзя — выпуск дрянного продукта будет виден всем, будет испорчена репутация многих участников проекта и самой компании, на следующий же день среди высшего менеджмента начнутся разборки и т. п.
А вот закрыть проект или перезапустить его, честно запланировав нормальный выпуск (и признав срыв сроков), — можно. И это по-мужски. - Конечно, можно выпустить проект в срок, но с ошибками. А я считаю, что нужно выпускать, когда получится, но зато качественно.
Комментарий: характерное предложение руководителя проекта при имеющемся уже срыве сроков, фактически - "отмазка". Безусловно, качественный продут лучше. Но только в том случае, когда срок "качественного" выпуска также точно зафиксирован. В противном случае эта нечаянная любовь к качеству — просто прикрытие срыва проекта и переноса сроков. - А куда мы денем руководителя проекта — мы ведь брали его именно под этот проект?
Комментарий: но ведь вы не брались обеспечивать его семью до конца жизни? Сильный человек найдет свое место в компании или за ее пределами; слабый ей в принципе не нужен. В любом случае это не аргумент для продления агонии проекта.
|
