Вы попробуйте сначала со своим ясельным уровнем не загнить за 40 лет, а потом критикуйте :)
В целом, все правильно, но с ограничениями по применению. Думаю так можно к примеру руководить дорожными рабочими или энтерпрайз разработкой в интеграторе. Но в гугле к примеру такое не прокатит.
Мне ближе позиция Джоела, который советует просто не брать людей, которым неинтересно программировать, и следовательно им нужна дополнительная мотивация — ваши пинания.
Как бы человек не любил свою работу, контролировать скорость все равно придется. Просто надо будет не пинать, а придерживать — хотя бы для того, что бы человек не загонял себя в ноль на каждом проекте.
Ага. Программистам нравится писать код, но часто это не тот код, который нужен вам. У Джоэла описаны мечты разработчиков. Реальность оказывается несколько приземленнее — на проекте бывает много задач, которые не нравятся ни одному разработчику. вот тогда и пригодятся вышеописанные методы. иногда этих задач может быть много.
Джоэл вообще-то не мечтатель (и уже давно как не разработчик), а совладелец FogCreek Software. И его принципы привели к прекрасному продукту, который я использую каждый день, и не перестаю восхищаться — Trello.
Я согласен, что задачи бывают не всегда интересны. Например сделать очередной шаблонный сайт. Но хороший программист найдет свой интерес — к примеру напишет автоматическую систему создания таких сайтов.
Ставлю себя на место работника, которым управляет такой Менеджер как вы.
Принцип 1. Выявить причины затягиваний работ
Вы над всеми там коршуном кружите? То есть ваша задача надзиратель? Если да, то я б на месте работника вместо того что б думать над задачей и сделать ее правильно, сделал бы «через ягодицы» лишь бы «всевидящее око» отстало и было довольно. А если не довольно, то так и так мне даст время на то, что я исправлю и сделаю в конце концов правильно. А начало бы штрафные меры принимать, послал бы лесом и шел в другой коллектив с более благоприятным микроклиматом.
И я предполагаю что вы обладаете даром предвидения, так как назначаете сроки, которые сразу учитывают все подводные камни которые могут появится…
Принцип 2. Пинать, пинать и еще раз пинать
Вас кто то сверху так же пинает? Или вы отчитываетесь за количество пинков.
программирование это творческий процесс а не работа тупой машины. Сегодня мозги могут работать отлично, а завтра так себе. Я в одном ритме работать не могу например. Ваша нога наверно ж то же устает каждый день с одной силой пинать…
Я считал что менеджер предназначен для эффективного управления ресурсами исходя из сложившейся обстановки. кому то кинуть на помощь и т.д…
Принцип 3. Концентрация на главном
>Иначе к концу срока Вы рискуете оказаться с перфекционистом, который ставит Вас перед фактом не выполнения работ, в связи с тем, что он пытался сделать все идеально для того, чтобы гордиться своей работой, и последующие поколения вспоминали его добрым словом.
То есть у работника нет никаких поводов для гордости своей работой, главное набрать строки кода и отстреляется. Печально. Да и в народе есть поговорка
«Если ты сделаешь быстро но плохо — все будут помнить что ты сделал плохо. Если сделаешь медленно но хорошо — все будут помнить что вы это сделали хорошо.»
Принцип 4. Не давать запудрить себе мозги
А что остается делать если неделю над багом сидишь и замыленным глазом просто его уже не видишь и сам уже нервничаешь что затягиваешь. И менеджер сверху по cron-у как Попка каждые пять минут «Ну че?… Ну че ?»
Вообще сложилось впечатление, что вас 15 лет так или иначе дрючили (причем такие же) и тут вы дорвались до власти… Дайте мне поводья…
И все ж когда работник мотивирован это гораздо лучше… Видимо мне повезло с начальством. Полная противоположность и все успеваем…
Отличные замечания.
К менеджеру должно быть в первую очередь уважение и понимание — что этот человек, который первым огребет если что-то провалится, поэтому его задача наладить эффективный процесс.
Большое уважение вызывают менеджеры, которые готовы иногда «вспомнить молодость» и раскидать пару куч говна в проекте, например с которыми не справляется новичок.
> Или у вас ЗП такие что заставляет терпеть?
В фирмах с такими «эффективными» менеджерами хорошей зп обычно и не пахнет. А насчет дрючили это вы в точку.
Психология раба. Его пинают унижают издеваются. Но стоит его возвысить немного над остальными как он сам начнет кнутом махать.
Последнее время на хабре зачастились вбросы бреда про то как «правильно» управлять проектами.
То что описал тс это еще цветочки, вот здесь вообще клиника habrahabr.ru/post/148138/
Давайте я вам отвечу, как инженер, наблюдающий коллектив изнутри.
1) Выявить причины затягивания сроков.
Таки да. Да, руководитель должен знать, в чем затык. Если исполнитель может честно и заранее сказать, что ожидаются проблемы по каким-то пунктам, то это хорошо. Если нет — то к дедлайну мы окажемся с неработоспособным решением и исполнителем, который «надеялся». И это косяк менеджера. Так что бдить надо. Хотя бы для того, что бы вовремя направить на помощь людей, обладающих соответствующими навыками.
2) Пинать, пинать и еще раз пинать
Кого-то надо пинать, кого-то надо сдерживать, что бы не сгорал на работе. Программирование — не более творческий процесс, как и любая инженерная деятельность. И да — бывают затыки, бывают проблемы, бывает ступор от усталости. Про затыки и проблемы см. п. 1, про ступор от усталости — видимо, менеджер не придержал ваши творческие порывы, и не выгонял с работы в 6 вечера. И это тоже его косяк.
3) Концентрация на главном
В бизнесе платят деньги за результат — то есть, за вовремя сданный проект, который удовлетворяет заказчика. Если вы можете сделать это в срок, и красиво, что бы было чем гордиться — вы молодец, ценный кадр и отличный специалист. Не успеваете — делайте, что б работало. Если хотите сделать медленно — то держите в голове, что заказчик может отказаться от проекта, потребовать снижения стоимость за затягивание работ, подать в суд — в общем, вариантов множество.
4) Не давать запудрить себе мозги
Если сидишь над багом неделю — см. п. 1. Скажите менеджеру, что проблема в этом баге, а сами устали в этом ковыряться. Скорее всего, можно будет подключить еще кого-то. Отделываться вечным «Сейчас-сейчас… Завтра будет» — это называется затягивать проект. А про затягивание сроков — см. п. 3.
Если бы все было так просто, как описано в статье, это был бы совершенный мир.
Можно я прямо по вашим пунктам пробегусь:
1. Подходите к разработчику каждые 20 минут и проверяйте его програсс — посмотрите, сколько у вас разработчиков останется через месяц. Если у вас адекватные разработчики, то о проблемах они вам сообщают сразу, как только они появляются, даже без люфта в 19 минут. А вот если вы набрали сотрудников, которые так не делают, это ваша проблема как менеджера.
2. Внутренняя мотивация в долгосрочной перспективе всегда выше внешней. Да, пнув разработчика сейчас (не читай новую статью на MSDN, а пиши говнокод), вы получите сейчас профит, а вот через год… Команда должна учиться, развиваться и решать поставленные задачи. Все это решается наиболее просто, если каждый сотрудник хочет работать.
3. Это вообще но комент. Я как практикующий программист, управляя своей командой не буду принимать решения что важно, а что нет. Мы не в детском саду, чтобы я говорил «так, все строем идем на горшок». Я посвятил проблеме час, программист 2 дня. Кто разбирается в проблеме лучше? Ну и как мне ему давать советы? А вот если вы за час разбираетесь в проблеме лучше программиста который корпит над ней два дня, то либо вы гений, либо набрали не тех людей.
4. Соглашусь, для менеджера в IT, весьма важен опыт работы в этой сфере, но не обязательно на разработческих должностях. Много хороших руководителей приходит из тестирования… Но, да, лучше если руководитель в прошлом программист.
1. А не надо каждые 20 минут подходить и спрашивать, ежедневный стенд-ап вполне для такого сгодится, либо небольшая доброжелательная приватная беседа. И это неверное, что «Если у вас адекватные разработчики, то о проблемах они вам сообщают сразу, как только они появляются», какой-нибудь интроверт-социопат может довести проблему до крайности и только потом сообщить, а при этом будет отличным разработчиком, пока дело не касается общения. К каждому свой подход нужен.
2. Стратегические цели далеко не везде вообще просматриваются. И нет ничего плохого в чтении МСДН, пока человек не делает это целый день вместо разработки, тут действительно стоит призадуматься.
3. А этот пункт вы, кажется, просто не поняли. Людям нельзя позволять делать то, что им нравится, в ущерб целям компании.
4. Лучше, если руководитель — хороший руководитель, если он ещё и программист, то вообще замечательно. Но если он только программист, но никакой руководитель, то тут всё, тушите свет.
Может быть я ошибаюсь, но я всегда думал, что «maneggiare» с итальянского значит «манипулировать», а уж кем манипулировать определяется идущим следом существительным.
Аналогично можно сказать, что «maneggiare» означает «погонять носорога».
maneggiare — это аналог слова manage на английском. а произошло от аналогичного разговорного на латыни — manidiare, которое в свою очередь образовалось из manus — «рука».
Я писал как есть — меня никто монстром-деспотом и тд не считает. Для меня это показатель что неоднозначная и даже более негативная реакция на статью. Показатель что правда — она никому не нравится…
а мне статья нравится честностью изложения, как чувствует так и пишет. Видно же, что не все так просто у человека. Видно, что трезво смотрит на себя, и свои поступки.
А то некоторые понапишут розовой лабуды и искренне верят в то, что именно такие они святые менеджеры, а по факту любо от них никакого проку, любо делает только хуже. А депрессии, апатию и срывы сроков вешают на сотрудников и т.д. и т.п.
Другое дело, что это совсем не единственный вариант менеджмента.
Точно. Согласен. Спасибо. Смелый человек попался. Не стал прикрываться красивыми речами… Я просто хотел подчеркнуть базовые вещи без розовых очков. Также подчеркиваю, что менеджмент это с одной стороны просто, с другой стороны надо иметь определенные особенности психики, что бы быть способным его успешно осуществлять. А потом масса книг, теорий, тренингов. И опыт и еще раз опыт. Без опыта — никуда.
>Я писал как есть — меня никто монстром-деспотом и тд не считает.
Возможно. Просто с первого прочтения (а я прочел раз пять, чтоб убедится, что понимаю ход мыслей автора и не урывками воспринимаю контекст) кажется слишком уж деспотичная… Суровый/Агрессивный вы манагер — так я подумал.
И все ж можете тогда показать/раскказать на примере как вы управляете своими подчиненными своим коллективом согласно пункту Принцип 2. Пинать, пинать и еще раз пинать
Коллеги, вы искренне считаете что все программисты святые, будучи программистами. Точно, ага. А дизайнеры наверное такие креативные, что им обязательно надо что-то нюхать чтобы гениальные творения делать? Я вас умоляю.
В советское время люди ракеты строили, атомоходы, подводные лодки и заводы. И никто не жаловался, что не дают времени ПОКРЕАТИВИТЬ. Программирование это работа, а не творчество. Если вы обладаете нужным уровнем знаний, то у вас не возникает вопросов КАК сделать ту или иную задачу. И вы видите в этом только рутину, от которой стремитесь убежать. Но никак не креатив. Креатив у программистов — это решение сложных задач, которые выходят за рамки ваших знаний и компетенций. А между прочим все великие писатели, ПРОФЕССИОНАЛЬНЫЕ писатели, а не талантливые самоучки!!!, говорили что писать — это ТРУД! а не просто вдохновение какое-то. Что писать это РАБОТА, которую нужно делать. Хочется или не хочется. И композиторы великие так говорили. А креативность не делает вас профессионалами. Она делает вас любителями. Нравится — делаю, не нравится — не делаю. Вот привезли вас в больницу аппендицит вырезать, а там доктор говорит — а у меня настроения нет. или я лучше почитаю пару статей интересных. нормально?
А есть еще такая вещь забавная, как микроклимат в коллективе. Если с самого начала менеджер носится как угорелый и пытается уложится в сроки, а все программисты читают хабр и ловят настроение вместо того, чтобы делать дело — переломить такую ситуацию очень трудно. Адекватно себя ведут программисты только в деловой атмосфере, когда есть культ личной ответственности каждого за конечный результат.
Могу только добавить — если вы хотите, что бы к разработке ПО относились, как к инженерной деятельности, то и работайте, как инженеры. Сам не программист (хотя к IT имею непосредственное отношение), но пару раз слышал от знакомых программеров жалобы на постоянно изменяющиеся хотелки заказчиков, изменения сроков и т.д. Когда спросил, есть ли согласованное техническое задание, согласовывали ли календарный план-график выполнения работ, что написано в техническом проекте — смотрели, как на больного и спрашивали, нафиг столько макулатуры.
Абсолютно согласен. Без четко определенного технического задания никогда не ставлю задач. Сам вырос из программиста до собственника компании и до сих пор выхожу в поле и SQL запросы подсказываю и код пишу. Но молодое поколение выросло на байках об элитарности бородатых сисадминов и романтически-раззвездяйской работе программистов. С трудом перековываем на нормальное человеческое отношение к результатам своего труда, ответственность и обязательность.
Мне поработать программером не довелось, но разницу между принципами типа «бери и делай» и инженерной деятельность понял так же на своей шкуре. Ехать в командировку с Firewall/VPN железякой, не имея на руках не то, что понимания, куда ее заказчику поставить, а банальной карты сети — это незабываемый опыт. Сейчас сижу, пишу себе проекты, по которым буду работать, и безумно радуюсь.
Мне кажется, они смотрели на Вас и думали — «хм, он вообще слышал об Agile?» :)
Существенным отличием разработки ПО от другой инженерной деятельности является возможность вносить изменения на всех стадиях проекта.
Это далеко не везде работает, конечно — но в производстве пушек или строительстве домов это невозможно В ПРИНЦИПЕ. В том и разница.
А «жалобы на..» — это обычное профессиональное ворчание.
Не обращайте внимания. :)
В советское время люди ракеты строили, атомоходы, подводные лодки и заводы. И никто не жаловался, что не дают времени ПОКРЕАТИВИТЬ.
Не было тогда такого опошленного слова. Люди просто делали свою работу, ракеты, атомоходы и т.д.
А потом придумали термин «креативность», которым по сути назвали интеллектуальный труд, но термин опошлили до невозможности путем использования его где можно и где нельзя. Как результат — все этого хотят, но «никто» не знает что это и «все» на это жалуются.
Программирование это работа, а не творчество.
Творчество по определению тоже может быть работой. А фраза «Программирование это работа, а не работа», согласитесь, звучит странно.
Если вы обладаете нужным уровнем знаний, то у вас не возникает вопросов КАК сделать ту или иную задачу. И вы видите в этом только рутину, от которой стремитесь убежать. Но никак не креатив. Креатив у программистов — это решение сложных задач, которые выходят за рамки ваших знаний и компетенций.
Если сотрудник работает только над задачами, решения для которых известны (рутина), то необходимость держать квалифицированных программистов на таких местах как-то не обоснована. Дрессированные кодеры будут и эффективнее и дешевле.Но как только известного решения какой-либо задачи не будет, тогда ой — система развалиться как карточный домик.
И вообще с моей точки зрения работа программистов, инженеров очень точно описывается следующей цитатой:
«бессмыслица — искать решение, если оно и так есть», в то время как настоящей проблемой будет — «как поступать с задачей, которая решения не имеет»
>Если вы обладаете нужным уровнем знаний, то у вас не возникает вопросов КАК сделать ту или иную задачу.
>Креатив у программистов — это решение сложных задач, которые выходят за рамки ваших знаний и компетенций. А между прочим все великие писатели, ПРОФЕССИОНАЛЬНЫЕ писатели, а не талантливые самоучки!!!, говорили что писать — это ТРУД!
Согласен и делается так. Но иногда есть желание (если никто не вьется сверху коршуном) сделать задачу красиво и элегантно, и потом разместить решение на хабре, что б кому-нить пригодилось то же. Но для этого нужно чуть-чуть подумать и раскинуть мозгами. Элемент творчества (креатива) должен быть. И не нужно путать с вдохновением. Мне никогда в голову не приходило отловить Музу что б покодить.
>Вот привезли вас в больницу аппендицит вырезать, а там доктор говорит — а у меня настроения нет. или я лучше почитаю пару статей интересных. нормально?
про то же. Когда нужно, тогда нужно. я могу ночами посидеть и поделать (хоть жизнь от этого пациента не зависит) так как мне важно, что меня манагер ЦЕНИТ а не относится как к СКОТИНЕ парнокопытной, которой нужно понукать…
И по статье явно прописано текстом, что все подчиненные, ленивые, вялые, вечно че то левое хотят покодить и т.д. И только супер-манагер держит весь проект, без него никак. Разбегутся… Видимо и премию себе потом выписывает, так как это чисто его заслуга.
Ну а почему бы не сказать так, в контексте Лошадь-Гонец:
Моя дорогая Лошадка. Для нас стоит общая задача доставить груз из Точки А в точку Б за неделю. Я выбрал тебя потому что доверяю, верю и знаю что ты можешь справиться. По этому пути будут и подъемы и спуски. Я не знаю твои характеристики силовые/скоростные в полной мере, поэтому сама оценивай где ускорятся, а где притормаживать. Я даже зарезервировал немного времени на то, что б ты могла травку пощипать (если необходимо) или вдруг ногу подвернешь (мне важна ты здоровой)…
Груз везти этой дорогой. Но если посчитаешь что есть путь короче или легче — можешь и срезать. Но если зайдешь в тупик, я буду сильно огорчен, так если по времени будем не успевать и мне придется самому впрягаться рядом с тобой… Раза три я могу так помочь, но больше б не хотелось…
От тебя мне нужно только: каждый день отчитываться сколько ты прошла уже, и сколько собираешься пройти в текущий день. Мне это действительно важно знать. Так как мне нужно сообщать купцу где сейчас его груз находится…
Поэтому учитывай эти моменты и не относить формально. Отписывай достаточно подробно…
Но если три раза накосячишь, или все ж не успеем во время доставить — я тебя пристрелю…
И знаете как то работает (в моей команде)… Правда один конек-горбунок два косяка уже успел сделать… Но он знает, что я уже начал чистить револьвер…
Все, у человека есть определенная степень свободы, и знает, что за оплошность его пару раз не отчитают, а еще и подставят плечо. Иначе может появиться комплекс, и он будет вообще боятся что то новое вносить. Но и знает чем чревато перегибать палку.
Иначе смысл работать в коллективе, которому тупо не доверяешь и смотришь им через плечо.
Да
начальник должен
1)знать чем занимаются подчиненные и какой статус у каждого задания чтоб иметь возможность реагировать на проблемы
2)Иметь авторитет среди подчиненных
3)Хорошо разбираться в предметной области (или полностью доверять людям которые в этом разбираются если начальник большой)
Но «есть нюанс» как это реализовать.
Дважды в день соберать отчеты с 5-ти минутной разбивкой кто чего делал? Устраивать показательный разбор завалов? Проводить на работе 14 часов чтоб дублировать работу и dev и qa и re?
А вечерней рассылки от исполнителей по проекту, кто что сделал за день, какие были проблемы и какие планы на завтра не хватит? Написание такого письма занимает минут 10.
Кому-то хватит, кому-то нет (например здорово узнать в конце дня что несколько человек были заблокированы чем-то что можно было разрулить за 15 минут). Кто-то и без отчетов все узнает. У кого то это займет 10 минут в день, кто то спишет на составление отчета 10 минут в час. Кто то из програмистов скажет что составлять отчеты это вообще не их задача. А почему не утреняя рассылка? А почему не статус-митинг? А почему два раза в неделю?
Про то и пост что сказать «держи руку на пульсе» легко, а вот устроить так чтоб все делалось «само» не раздражая подчиненных и не заваливая начальника это и есть скил.
По-моему, взаимодействия в течении рабочего дня никто не отменял. И если сотрудник продолбил день из-за чего-то, что можно было разрулить за 15 минут — то он дятел, и достоин внушения в стиле «догоняешь сроки в рабочее время без доплаты». Повторю — если это специалист продолбал. Если менеджер был поставлен в известность об этой проблеме, то продолбал уже менеджер.
Вечерняя рассылка — это как пример. Она может быть утренней/статус-митингом и вообще чем угодно, что позволяет руководству получить информацию о состоянии проекта. Аналогично и с частотой таких собраний. Все настраивается в зависимости от многих технических и политических моментов.
мы вроде об одном и том же — я не говорю что это не возможно или архисложно настроить, лиш о том что задавшись целью это настроить можно как достигнуть успеха так и накосячить. И тут есть ряд технических и политических моментов которые надо как минимум учитывать. А аффтор ничего на эту тему не говорит, только «контролируй». Причем преподносит это как ноу-хау, мол мужики и не знают что причины застопореных работ менеджеру надо знать.
На всякий случай целиком анекдот на который я ссылался
«Пришли мыши к филину и жалуются: «Мы такие маленькие, нас все обижают, что нам делать?» — «Надо вам ежами стать- их не обижают!» Мыши обрадовались, а потом задумались: «А как нам стать ежами?» Снова идут к филину с этим вопросом. «Не знаю как, я — стратег!» — отвечает тот.»
Грамматику и пунктуацию что ли отменили? Читать сложно…
По теме — самое смешное, что нынешнее мое руководство не отслеживает прогресс по проектам. И если я стараюсь донести до начальника причины затыков, то не все мои коллеги это делают. И начальник у меня вроде не вчера на руководящую должность пришел. И тем не менее.
Статья, к сожалению, на уровне профессионализма девочки, только что закончившей «менеджерскую» специальность экономического факультета провинциального ВУЗа. Она эффективна для «клиниг-менеджеров», «офис-менеждеров» и «топ-топ-менеждеров» и оторвана от реальности управления людьми, занимающимися интеллектуальным трудом. Теперь я не удивлен такой беспросветной тупизне некоторых управленцев, начитаются подобного бреда и «куроводят» коллективом.
Камрад, за недолгое время с 1988г.р., Вы, судя по комментарию, успели стать сильнейшим менеджером. Моей компании требуются такие молодые и профессиональные сотрудники. Во сколько Вы оцениваете свой труд?
Мой многолетний опыт управления разработкой подтверждает сказанное :(. Пинать, пинать и еще раз пинать. Внимательно следить чтобы не отклонялись от курса. Снимать с ушей лапшу и снова пинать :).
Склад Печенек. Специальное место, где легко ловить и пинать разработчиков, сотрудников отдела тестирования и маркетологов. Вокруг Склада смонтированы Кофемашины, Кухня и Переговорная :).
Да как-то успел и поработать в команде, которой руководил подобный менеджер и руководить командой сам. Поэтому Вы зря иронизируете и переходите на личности. И да, в работе менеджером, к Вашему сожалению, пока не заинтересован. Хочу, так сказать, набраться опыта «на поле боя» и добавить пару-тройку строчек в резюме. Сугубо профессиональная стратификация, так сказать.
Жаль что все скатилось на иронию. Надеялся, вдруг исключение. Вот приходят ко мне молодые успешные люди, на руководящую должность. Вот только руководить не получается у них. Учишь, наставляешь, все бесполезно. Прям болезнь какая-то.
Все они считают что умеют управлять, а по факту все управление сводится к раздать поручения и сидеть в пасьянс играть ждать когда придут и скажут что все сделано. Не удосуживаются даже проверить выполнение. И абсолютно развращают специалистов. Грустно от таких «управленцев».
Руководитель первого уровня должен быть вихрем, который закруживает вокруг себя всю свою группу. Наставником, советчиком, примером живым, лучшим специалистом и еще много слов.
Конечно, не хочу судить по вырванным из контекста фразам, но складывается впечатление, что Ваша ситуация мне знакома. Отношение к программистам как (возможно, ошибусь с метафорой) типографским наборщикам с зарплатами code monkey, пара-тройка архитекторов, вероятно, с которыми бизнес и стартовали (или нашли на первых проектах). При этом, вас, очевидно, устраивает описанный подход к управлению.
Для полноты картины, назовите приблизительный процент текучки кадров-исполнителей первого уровня в год и размер компании. Не хочу судить по аватарке :-)
Proconsul означает прогноз-консультант. Кто в теме, те знают.
Занимал должность директора веб-студии, второй по размеру в федеральном округе, брали проекты не менее 300т.р. и до 10-12млн. Отношение к программистам нормальное, в компании есть и дизайнеры и архитекторы и ведущие программисты и стажеры.
В институтах обычно учат программировать, но не учат работать. Стажеры обычно или уходят в течение первых двух недель как «пусть их учат другие», или остаются как «человек адекватный, работать научится». Некоторые растут быстро и способны выполнять сложные задачи не тормозя, а активно консультируясь с ведущими. Некоторые не хотят\не могут развиваться, но берут стабильностью результатов.
Конкретно у меня сейчас руководители групп управляют не программистами, а операторами ПК, которые выполняют несложные регламентированные функции. Обрабатывают информацию. Можете представить себе для примера, скажем, копирайтеров. Проблема в том, что компания очень быстро растет. Нужно расширяться. И за 30к (не Москва!!!!) невозможно найти нормального руководителя группы из 3-5 человек. Или толковые управленцы, которые стоят от 60к или одно название.
И потому под каждым словом автора готов подписаться. Прописные истины, которые всегда имеют место.
Спасибо. А то забавно читать комментарии тех кто еще не менеджер или тех кто туда недавно пробился. Конечно немного жестковато получилось… Особенно не приятно читать тем кто по ту сторону барьера. Таких большинство. Слащенную пилилю им подавай про светлое будущее и гуманизм. Естественно что не все так просто как в статье. Куда все глубже, тактичней, умней и вежливей. Просто надоели карикатуры на успешных управленцев. Базар только и сопли разводят, а результата от них ноль.
Проверять — это ОЧЕНЬ сложно, я на своей шкуре это испытал. Иногда превращается в какую-то очень утомительную работу типа сапёры: начать разговор о погоде, о том поговорить, о сём, плавно подвести разговор к теме, потом увести… А если просто напрямую спросить, то часто обижаются как-то типа «ты на не доверяшь что ли?» (про себя, конечно). Ну или ещё какая-нибудь негативная реакция. Часто человек боится сказать, что потратил день на одну функцию, потому что у себя пробел в знаниях обнаружил и полдня читал документацию по ней и другие статьи, чтобы понять, как всё делать.
>Руководитель первого уровня должен быть вихрем…
отлично сказано!!!
Я когда своих наставляю обычно использую образ паровоза, которой тащит поезд, но эта метафора мне тоже нравится
О, кстати, о личном. Работая управленцем вот уже 2 года, работал по всякому, и с ТЗ и без него, и с квалифицированными спецами и без, воспитывая и учась, всегда по разному, вот не умею я контролировать себя и дисциплинировать на один и тот же подход.
Всегда есть нюансы, факторы и отсутствие печенек.
За два года ни разу не сорвал сроков, хотя иногда просто забывал про проекты, очухиваясь когда мне их готовыми приносили. ИМХО, именно поэтому руководят не программы, а люди, со всеми вытекающими.
И чем больше люди сами себе придумывают программ действий, тем меньше этот человек нужен.
За два года ни разу не сорвал сроков, хотя иногда просто забывал про проекты, очухиваясь когда мне их готовыми приносили. ИМХО, именно поэтому руководят не программы, а люди, со всеми вытекающими.
Просто когда я читал «ДАО Тойота», и увидел, что там управление строится на философии (и лишних костылей они не любят), понял, что такая философия есть и в России, просто не настолько осознанная. И попробовал ей интуитивно следовать.
А автор реально работает по этим принципам? или просто статья ради статьи?
Сорри, но, имхо, ваши принципы учат быть плохим проектным менеджером.
Куча умных книжек по управлению проектами, кажется, будет много полезнее для начинающих, как минимум, они расскажут о стандартных подходах управления проектами:
Сделай план, обсуди план с командой, обсуди сроки и реперные точки, распредели задачи по участникам команды, назначь регулярные встречи для апдейта текущих статусов задач и поехали…
И пинайте себя самого почаще, например, когда забыли запланировать задачку и бежите к разработчику со словами «А вот тут еще нужно сделать вот это».
А применительно к команде забудьте слово «пинать» и вспомните, что ваша команда — это люди.
А Вы считаете, что менеджер — это начальник, а участники команды — его подчиненные? По-вашему, например, разработчик должен беспрекословно подчиняться менеджеру?
Если так, то Вы слегка застряли в прошлом — скорее заводите свою машину времени… Сейчас все чаще, в ИТ стартапах, команда — это равноправные участники со своими персональными зонами ответственности. Например, менеджер, наравне с остальными участниками команды, организует общий процесс работы (цели, планы, сроки, ресурсы, приоритеты и т.д.), менеджер создает условия для комфортной работы участников команды… и т.д. и т.д.
А идеальных людей скорее не бывает! Более того, у каждого свои проблемы и т.п. И на регулярках по проекту часто может звучать «Парни, я опять зафэйлил задачу», но если это регулярно звучит от одного и того же участника, рано или поздно, команда будет вынуждена расстаться с таким участником. И этим участником может быть Менеджер.
Да, менеджер — это начальник, у него больше власти и больше ответственности. Нет, я не считаю, что разработчик должен беспрекословно подчиняться, не в армии находимся.
… ну если не в армии, тогда не понятно как именно реализуется на деле «больше власти и больше ответсвенности»?
На мой взгляд, менеджер по сути ничем не отличается от разработчика или дизайнера, он делает свою часть проекта как и все участники команды — вносит свой вклад в успех проекта наровне с остальными.
Для успешности проекта каждый должен нести одинаковую ответственность за свою работу. Т.е., условно, если менеджер четко спланировал проект, согласовал сроки с разработкой, а разработка срывает эти сроки, то это ответственность разработки. Но и если менеджер, забыл что-то включить в план и из-за этого поехали сроки разработки, то это ответственность менеджера. И организационная, и производственная части проекта одинаково важны, поэтому мне больше нравится идея когда все участники команды имеют одинаковую власть и отвественность — такая проектная «демократия» ;)
Знаете, есть такой замечательный принцип — единоначалие. То есть, начальник, принимающий решения, должен быть только один. Если у волка кроме головы начинает думать еще и хвост — то такой волк в лесу долго не протянет. «Проектная демократия», о которой вы говорите — это тот самый случай.
Распределение ответственности — перед кем? Перед заказчиком или перед топ-менеджментом? А какая для них разница, из-за чего был продолбан проект? Разбираться еще и в этом? Мало того, что продолбали проект, так вы предлагаете им еще и тратить свое время (и деньги), выслушивая препирательства на тему «кто тут злобный дятел»?
Менеджер принимает решения — о составе работ, о сроках исполнения, о составе проектной команды, и так далее. Да, команда вносит предложения, но решение остается за менеджером. Это значит — больше власти. И это же значит — больше ответственности.
Перед заказчиком и руководством ответственность несет менеджер. Никому не важно, почему был провален проект, выхватит за это РП. Разработчики от него выхватят, но если менеджер начинает прикрываться своими бойцами — гнать такого менеджера ссаными тряпками.
Да, посути нет одного единственно верного подхода в управление проектами.
Кто-то ставить себя выше команды, кто-то предпочитает быть на ровне с командой. Я предлагаю, смотреть на менеджмент немного под другим углов, и не факт, что это всем подходит, что все разделяют такой «демократический» подход.
Единоначалие безусловно должно быть, и на мой взгляд в конечном итоге — это заказчик проекта. Только заказчик реально принимает решение «о составе работ, о сроках исполнения», а менеджер проекта организует процесс исполнения в срок поставленных требований (транслирует их команде).
Менеджер проекта внутри команды также не определяет сроки и состав работ, а договаривается с участниками проекта (с team lead'ами и т.п.) что и в какие сроки должно быть сделано и далее выстраивает порядок выполнения задач, организует внутреннее взаимодействие участников команды, ведет контроль соблюдения сроков.
На мой взгляд менеджер проекта находится в полной власти участников команды, он целиком и полностью зависит от них, от них зависят и все сроки и качество. Менеджер проекта ставящий себя выше команды (у которого больше власти), скорее обречен на неудачу по сравнению с менеджером, который в команде наровне с остальными участниками, когда основной принцип взаимодействия — это диалог/обсуждение (пусть даже иногда «до последнего несогласного») и коллегиальное принятие решения.
Вы ярко сказали про волка, и четко объяснили почему «больше власти/больше ответственности», но как по-вашему в реальной жизни реализуется «больше власти/больше ответственности»?
Если менеджер в команде занимается тем, что транслирует требования заказчика команде — то грош цена такому менеджеру, и гнать его надо, дармоеда.
Если заказчик будет определять сроки и состав работ, требования к контролю качества и прочее — то работать команда будет 24/7, причем — за еду. Потому, что заказчик хотел все, сразу и за спасибо. Скажу даже больше — очень часто заказчик вообще понятия не имеет, какие работы ему нужно произвести. У заказчика есть некоторая потребность — это цель проекта. Исходя из нее (переведенной с языка заказчика на язык команды) менеджер, в комплекте с командой садятся, и считают, сколько потребуется на это времени, сколько и каких ресурсов, и какие, собственно работы, и как это согласуется с целью проекта. После этого менеджер считает себестоимость проекта, накручивает маржинальность, и идет с этим к заказчику. И начинает вести переговоры обо всем — о ценах, сроках, и так далее. Это только та работа менеджера, которая выполняется на этапе инициации проекта. Причем — это только работа с заказчиком.
То есть, исходя из этого мы видим, что работа команды на этапе инициации проекта сводится к выработке способов достижения цели проекта. А работа менеджера — выбор способа реализации проекта (если их несколько), определение финансовой выгоды от реализации проекта (а это уйма финансовой работы), переговоры с заказчиком (а после переговоров — повторяет все от выбора реализации до финрасчетов), переговоры с руководством, добывание ресурсов (если их нет — снова все повторяем). Зона ответственности менеджера выше, чем зона ответственности команды.
При закрытии проекта ситуация примерно такая же.
Менеджер на находится в полной власти команды. Менеджер ей управляет, распределяет премиальные и принимает решение о том, кто будет работать в его команде. Его вообще нельзя от команды отделять — это «голова» команды. Разводить демократию — это про того самого волка.
На практике это выглядит так:
Менеджер принимает решения. Менеджер дуплится за провалы. Если продалбывает боец — менеджер заставляет дуплиться бойца. Но для всех — как руководства, так и заказчика — ответственен за провал только менеджер. Не смог построить работу так, что бы все было сделано в срок — его косяк. Не смог заставить бойца отрабатывать косяки в нерабочее время — его косяк. Не смог выбить необходимую доходность и прощелкал проект — его косяк (и плевать, что это команда находила варианты решения! Переговоры с заказчиком вела не команды).
Учитывая высокую ответственность, у него больше власти. Все просто.
Принцип 1 — нужно развернуть. Не так уж просто определить, что именно затягивает работы.
Принцип 2 — спорно, здесь к разным людям нужен разный подход. Возможно вы работали лишь с теми, кого нужно пинать, а остальные с вами не уживались и уходили (а вы сделали ошибочный вывод, что все подлежат пинанию).
По мне — это тактические принципы, которые заставляют проектного менеджера заниматься микроменеджментом, который и будет съедать всё его время. А вот стратегические задачи останустя за бортом, такие как: совершенствование процесса, совершенствование команды. В данных принципах (особенно в 1,2 и 4) сквозит директивным стилем руководства, а это низшая форма работы с подчиненными (а эти подчиненные получали высшее образование, и писали у себя в резюме, что они креативные, инициативные и обучаемые… а мы их к обезъянам приравниваем)
Но я не хотел бы говорить, что принципы не рабочие, скорее с них надо начинать, а потом переходить к стратегическим вещам таким как:
директивное руководство -> делегирующее руководство
управление человеческими ресурсами -> управление человеческим капиталом
и т.д.
Работа руководителя неблагодарна, т.к. хороший руководитель должен построить процесс таким образом, чтобы там всё работало без него.
Несколько комментариев и своих мыслей, которые хотел бы обсудить.
«Принцип 2. Пинать, пинать и еще раз пинать»
Как-то легко у автора получается — как-будто его компания — одна на рынке и все мечтают в ней работать.
Ресурс «программистов» — очень трудно возобновляемый.
И если каждый день «пинать, пинать» — то лучшие из них просто разбегутся, благо рынок труда сейчас ох какой горячий.
И что тогда делать?
К сожалению, разработчики — натура зачастую «тонкая», с которой надо уметь общаться — поэтому «печенек» в т.ч. и переносном смысле должно быть не менее, чем пинков.
А об этом ни слова в статье.
«Принцип 4. Не давать запудрить себе мозги»
Здесь важно иметь сотрудника (тим-лида, архитектора, разработчика..), который глубоко разбирается в предмете и которому ты безоговорочно доверяешь — иначае никак.
Каким бы «крутым» ты не был в прошлом — пройдет 2-5 лет — и все… мозги тебе пудрить будут на раз, а держать уровень ну никак не получится — времени на это просто нет — останется только «широкий кругозор».
Программисты — очень тонкие натуры, это да. Но если периодически не пришпаривать их, они расслабятся и будут перфекционировать, растягивая сроки неимоверно. Это, может быть, и не плохо для большой кампании, в которой много программистов, очень большой, сложный, неповоротливый проект, в котором новый код появляется на продакшене только месяца через 2-3. Но для маленькой команды, для нового либо динамично развивающегося проекта это губительно.
А особенно пинать их надо, если вместо работы они сидят на хабре или ещё где-нибудь.
В статье описан интуитивно-понятный принцип абсолютно неправильного управления, приводящий к катастрофическому росту неразберихи в компании, чуть только она вырастает за 50 человек.
По поводу лошадей, помимо того, что они здесь нипричём, как кто-то уже упомянул. Пятками лошадей не подбадривают. Есть такое понятие — шенкель (см google). И под уздцы лошадь брать не надо, чтобы изменить направление движения. В общем, я к тому, что мне кажется, что хороший руководитель должен всё-таки что-то понимать в том, о чём он говорит.
У пары умных людей прочитал, что есть 4 причины по которой исполнитель не выполняет задачу в срок.
1) Нечеткая цель. То как понял задачу исполнитель и то как ее представляете себе вы — разные вещи. Чтобы с этим бороться нанимают аналитиков, пишут ТЗ, доносят vision проекта до исполнителей, ведут список задач, пишут user stories и т.д.
2) Нет знаний \ умений. Исполнитель просто не умеет решать поставленную задачу. Выход — либо учить (книги, курсы, помощь старших), либо поручить задачу другому.
3) Нет возможности. Это вопрос планирования — загруженность людей, наличие других задач, приоритеты. Особенно остро вопрос встает в компаниях с матричной структурой. В статье прозвучала мысль, что надо знать кто чем занимается, и сколько планируется на каждую задачу потратить времени, чтобы озадачить именно того человека, у которого будет физическая возможность сделать задачу.
4) Нет желания. Вот бывает и такое — и задачу понял, и знания \ умения есть, и время выделено — но не делает. Вот только в этом случае (когда отброшены остальные варианты) нужно садиться с человеком и разговаривать — почему он не хочет этого делать. У него сезонный депресняк, или хочет другую работу, или еще что-то. И варианты решения этой проблемы тоже есть — увольнение это один из самых дорогих и неэффективных методов решения. Хотя, соглашусь с другими комментаторами, что нанимать программистов, которым вообще программирование не нравится — странный подход.
Если вместо принципа №1 в вашей статье применить вот эти четыре пункта, то остальные принципы можно выкидывать.
Comments 69
Only users with full accounts can post comments. Log in, please.