Как стать автором
Обновить

Комментарии 79

на случай если когда-нибуть буду руководителем, добавлю пост в избранное
как бы так дать аккуратно почитать этот пост начальнику…
Тут я думаю тут вариант один, если начальник у вас толковый (адекватный, нужное подчеркнуть), он сам найдёт эту статью.

Это я вам как руководитель одного маленького проекта говорю (:
дело в том что он не ищет способа как более эффективно и правильно управлять разработчиками, а должен был бы!
Значит он не очень толковый/адекватный(
Мне кажется что толковый или адекватный начальник сам такие статьи писать может.
Может, но напишет что-то свое. Расти можно бесконечно, тем более в такой необъятной области, как управление персоналом.
Просто скиньте ссылку в _____ (jabber, email,… — подставить нужное).
Это я Вам говорю тоже, как руководитель -)

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

За Чуковского отдельная благодарность (:
Для PM у вас крайне уникальный для нашей действительности взгляд на управление. К сожалению большинство увлекается именно технической стороной руководства проектом.
Это вполне себе обыденный взгляд на управление. Можно даже сказать, по книжке.
Вы извините, но я скажу — хочется работать в вашей команде *смутился_и_закрыл_вкладку*
Как только стану Pm'ом, достану пост из закладок
НЛО прилетело и опубликовало эту надпись здесь
В избранное, хоть я и не руководитель сейчас. Но пригодится, спасибо.
У меня есть несколько «заваленных» проектов, в основном по срокам. Буду признателен, если вы продолжите эту тему! Пост на 5 с +.
Можете описать, что ИМЕННО должен делать ПМ? Конкретно, а не просто «руководить»… Хочу определиться, какие функции на него возложить, и кого из программистов «прокачивать» до руководителя.
Насчёт прокачки — оно не очень хорошая идея. Тут не прокачка нужна, а склад души, что ли… Вообще, программисту и ПМу обычно нужны прямо противоположные качества (почитайте Рейнвотера, у него это прописано). А если уж сильно нужно «превращать» (а не прокачивать) кого-то из команды, попробуйте спросить, кто из ваших программистов готов стать руководителем проектов, если ему при этом уменьшат зарплату (хотя бы немного). Если таковые найдутся — присматривайтесь к ним, они и есть потенциальные руководители.
ОГО! Уменьшить? И каким образом вы можете это объяснить?
p.s. Спасибо за Рейнвотера («Как пасти котов. Наставление для программистов, руководящих другими программистами») — пошел читать :)
Объяснение простое — мотивация. Если человек готов ради долгосрочного развития (и более интересной с его точки зрения работы) поступиться краткосрочными выгодами — это многого стоит и за такими людьми, правильно написано, нужно присматривать.
А что вы подразумеваете под ПМ? Производственный менеджмент или финансовый? Сначала опишите ваше видение этой должности, чтобы понимать, кто именно вам нужен.
ПМ-PM — Project manager. Конечно же производственный
Тогда он должен бесперебойно подносить патроны работникам. Другими словами, работник в любой момент времени должен иметь четкое и ясное представление о своей задаче, сроках и методах ее реализации.

Неправильно поставленная задача:
Иван, сделай там по-быстренькому чатик заказчику…

Правильно поставленная задача:
Заказчик планирует внедрять систему быстрого реагирования на проблемы пользователей. Для этого мы должны интегрировать ресурс xyz.com в наш продукт. Документация по API этого сервиса лежит по адресу такому-то. Дизайн блока предоставит работник такой-то через столько-то часов, другие изменения дизайна не планируются. Срок реализации — столько то часов. Дедлайн такого то числа. Предварительный прототип — такого-то числа.

Вторая задача ПМ-а, следить за приоритетами задач и вовремя изменять приоритетность.

Третья — контроль информационных потоков. Наилучшие или удачные решения должны выноситься на публику, команда должна понимать, кто что делает, какие приемы или решения сейчас применяются, и так далее.

Четвертая — отчитываться перед руководителем о расходах бюджетов.
Про виноватых согласен — «ПМ ответственен за крах проекта, разработчики — за успех проекта!» :)
Я вот тут написал статейку про обязанности менеджера.
Вкратце:
1. Постановка целей
2. Организаторская работа
3. Мотивация работников и общение с ними
4. Измерение показателей
5. Развитие своих подчиненных
Ну вроде бы прописные истины (Демарко etc.), а все-равно приятно, когда человек после года практики пишет не разочаровавшись, а наоборот. Значит справился, значит хороший ПМ. Приятно читать :)
«Всё верно, бумага написана правильно, всё-всё хорошо». Но есть нюанс. Он, как всегда, во взаимопонимании. Когда у тебя в команде четыре человека, можно общаться с каждым лично, вникать во все проблемы и быть классическим правильным руководителем в стиле «слуга царю, отец солдатам». Но когда людей становится больше и больше, все эти прекрасные идеи так или иначе искажаются, и руководитель рано или поздно встает перед выбором: принять «непопулярное» решение или нести убытки. Если он ставит интересы членов команды выше интересов дела, то дело рано или поздно развалится.
«Но когда людей становится больше...»

А не должно становиться больше. 6 человек. команда.
Дальнейший рост — путем создания еще одной команды.

Ну и как будто в маленьких командах «непопулярные» решения принимать не приходится.
Приходится, но реже, и всегда можно лично каждому объяснить, почему так произошло. А по поводу «не должно становиться больше» — соглашусь, чем меньше, тем лучше. Но жизнь обычно далека от абстрактных моделей, описанных в специальной литературе.
К сожалению, не имел опыта руководить большой командой (максимум — 9 человек, включая программистов, QA, аналитика и меня). Поэтому пост написан именно с этой точки зрения.

Где-то читал (по-моему в теории FDD), что большие команды стоит разбивать на несколько маленьких и ставить во главу каждой грамотного тимлида — этакая иерархия получается. Но это исключительно теория. Поскольку сам с большими командами не сталкивался, то рассуждать на эту тему не берусь.

А что касается «непопулярных» решений, так их приходится принимать и в маленьких командах, к сожалению.
Да-да, принцип «разделяй и властвуй» неоднократно проверен как в практике управления командами, так и в ходе мировой истории в целом. По поводу непопулярных решений: как я уже упомянул чуть выше, чем меньше людей, тем меньше поводов такие решения принимать. Но даже если приходится, в маленькой команде легче предугадать последствия и нивелировать негативные реакции.
С точки зрения психологии, в команде до 9 человек каждый разработчик может более-менее представлять, кто и чем занимается и за какую часть работы отвечает. Поэтому и взаимодействие внутри небольшой команды эффективнее и проще. 5-7 разработчиков на группу- это идельно с точки зрения взаимодействия между ними. Микрогруппы редко выходят за эти пределы.

Человеку свойственно воспринимать команду, как единое целое, если она не превышает 12 человек. Если больше- команда начинает разделяться именно на уровне восприятия, люди не воспринимают команду, как единое целое, появляются «фрагменты» (базисты, интерфейсники, тестеры и т.д.), даже если формально такого деления нет. Если в команде есть граница, по которой может пройти такое разделение, то команда может поделиться и сама, причем эффективно, однако если такой явной границы нет, может оказаться, что люди, которые выполняют смежные задачи, окажутся в «разных» частях. Такое деление способно привести к тому, что люди одной группы будут слабо представлять, что делает другая, а в условиях, когда между разработчиками требуется постоянное взаимодействие, это снижает его эффективность.

Поэтому и полезно большие команды разделять на более мелкие, распределяя между группами относительно независимые задачи. Понятно, что если команда 9 человек, включая архитектора, тимлида и аналитика, то делить ее смысла нет, только хуже будет.
Tomcat, а сколько душ в твоей команде сейчас?
Сейчас — пятеро. В компании некоторая реструктуризация, поэтому людей теряем, к сожалению.
ПМ, аналитик, архитектор, QA и тимлид? А где негры??
У нас всю работу белые люди выполняют. Им даже нравится ;)
Смешно сказал. Я имела в виду рядовых разработчиков. Истинных арийцев, конечно. У вас их есть, не так ли? Кто мужики, а кто генералы в твоей пятёрке?
Я это понял, просто хотел уйти от ответа. Не получилось :).

Из пяти человек просто нельзя «выделить» отдельного человека на черновую работу. Для того, чтобы такой малой командой эффективно выполнять проект, необходимо. чтобы каждый из них, как минимум, достаточно серьёзно разбирался в архитектуре. У каждого есть область технических задач, в которой он принимает решения.

Я осуществляю общую координацию проекта. Ежедневные митинги помогают всем быть в курсе того, как обстоят дела у остальных. Серьёзные архитектурные решения обсуждаются. Последнее слово в дискуссиях, очевидно, за ПМом.

Когда команда будет больше, появится тимлид, через которого централизованно будет проходить архитектурная информация. Пока не вижу смысла (сейчас мы некоторое время занимаемся исключительно саппортом, готовимся к новому проекту).
А вот на этот раз получилось.
За сим позвольте откланяться.
Проблема большинства ПМ в ИТ-компаниях в том, что они выросли из программистов. Программисты — циники по натуре и им намного проще работать с программами и процессами, а не людьми. Поэтому появляются монстры-методологии, на которые возлагаются надежды автоматизации процесса управления. Методологии хороши на крупных проектах с большими командами. А для большинства мелких компании-разработчиков достаточно факта планирования.
К сожалению, в небольших же компаниях на ПМ вешают и обязанности аккаунт-менеджера, хорошо еще если и не сейла. В результате имеем, что имеем.
>Ну, действительно, что будет, если программисты начнут договариваться с заказчиком о сроках, а специалисты по продажам – тестировать код?
А если немного «подправить» систему и переодически делать отступ от правил, действительно ли будет плохо?..

Спрашивать сроки и у программиста. Во первых программист начнёт реальней оценивать работу, потому что если он сказал «неделя», а справился за две — он понимает, что виноват он, а не «тупой начальник давший не реально короткие сроки». Во вторых — это даёт чувство ответствености и участия. Когда чувствуешь себя участником проекта, а не «гайкой», то и мотивация появится.

Давать маркетингу тестировать систему — это увеличить знания о товаре. Возможность маркетингу узнать о сильных сторонах, а разработчикам о слабых (фидбек пользователей со знанием принципов «привлекательности» товара и интереса клиентов). Когда продаёшь продукт в который веришь и который знаешь — это видно.
спрашивать сроки у программиста бывает опасно
можно обсудить сроки по планируемой задаче,
но итоговую оценку надо самому принимать
учитывая сложность задачи, навыки программиста, придирчивость заказчика + возможные доводки
+ программиста просто нет все информации по задаче, а только что-то локальное
однажды я с удивлением обнаружил, что архитектор CRM-системы никогда не занимался обзвоном клиентов с использованием своего продукта и как следствие там были не учтены многие элементарные моменты
Тут немного не о том я хотел сказать. Прежде чем дать оценку задачи я, в большинстве случаев, спрошу у программиста (а потом оценю реалистичность и введу коррективы, если посчитаю нужным). И потенциальному пользователю показывать систему обязательно. И это — факт.

В слове про сроки ключевое слово было не «сроки» а «договариваться с заказчиком», а под тестированием понимается реальный процесс QA с составлением грамотных багрепортов и т.д. Здесь я хотел сказать, что каждый должен делать свою работу. Ну не заставлять же, в самом деле, маркетологов багрепорты писать в трекер.
А что автор хотел пообсуждать? не вижу никаких поднятых вопросов…
думаю это его рекомендации к действию и выводы из практического опыта
Ну, по большому счёту, хотебось бы понять, насколько это согласуется с практикой в других командах. Возможно, у кого-то появятся дополнительные идеи, которыми я сам смогу воспользоваться.
«На самом деле, в провале проекта никто кроме руководителя не виноват.»
Вот за это 5. От этого и надо отталкиваться. В команде должно быть четкое распределение ответственности. Кто моет посуду, кто кофе греет, а кто за пиццей бегает иначе будет бардак, выяснение отношений и сваливание вины на других.
Интересно, а во всех странах принято вискарь директору вручать или это наше ноу хау?
А я то думаю, почему нет вакансий на ПМ в ИТ компании, а ПМов просто берут из программистов.
По поводу поста вы сами написали Капитан Очевидность, то есть все в общем то очевидно и нет предмета для дискуссии. Если только кто опытом поделиться, опытом разруливания межличностных отношений в команде. К сожалению, человека действительно нужно постоянно мотивировать и работать с ним на психологическом уровне. Мне иногда кажется, что хорошим ПМом мог бы быть проф. психолог, а не программист.
Мое сугубо личное, к сожалению, подтвержденное опытом, мнение:

— В 70% руководителями — в полноценном смысле — не становятся, а рождаются. Со временем только кристаллизируются и набираются практического опыта в вариативности подходов, взглядов и конкретных практик управления людьми, как с точки зрения психологии, так и с точки зрения организации, в том числе собственной.

— В 30% — настоящие руководители получаются из целеустремленных и профессиональных исполнителей, когда они очень много времени уделяют собственному образованию в менеджменте/психологии/социальном управлении.
Давай те не будем вводить людей в заблуждение — правильные цифры 50% и 50%. :) Вот например мой случай. Я появился на свет с врожденным повышенным уровнем ПМства в крови: в 1 год я уже строил игрушечные замки из кубиков, в 3 года — сдал на сертификат PMP, в 6 — открыл небольшую, я бы даже сказал микроскопическую, компанию по производству софта — микрософт :) Верите??? Есть только 2 фактора для становления настоящих руководителей: труд (книги и практика) и везение (вменяемое руководство, зрелая компания). Генетическая предрасположенность отражает лишь заложенный потенциал, да и то лишь в некоторой степени.
Сказок не бывает, поверьте
а как вы отличаете людей те которые «кристаллизируются и набираются практического опыта» от тех кто «очень много времени уделяют собственному образованию в менеджменте/психологии/социальном управлении»? Ведь чтобы посчитать проценты надо их как то отделять друг от друга?
Как минимум — реальное практическое/жизненное понимание и детальное знание развития профессиональной биографии того или иного руководителя.

+ Непосредственное практическое взаимодействие.

Это, если говорить о руководителях в полноценном смысле, а не о случайностях.

Подобные вопросы, впрочем, достаточно академичны, всесторонний анализ даст вам ответы на все вопросы.
Пользуясь случаем, передаю привет Гошиному роботу-трансформеру.
Я не ПМ, но мое мнение о том, каким он должен быть, полностью совпадает с вашим.
Про «уволить человека с которым пил пиво» написано — но углублю. Не только уволить, но и просто сделать замечание, поручить делать непопулярную/неинтересную часть проекта, в конце концов, заставить отвечать за сроки — очень психологически тяжело. Причем насколько руководителю, настолько и подчиненному. Поэтому панибратство и тесное дружеское общение с подчиненными не очень хорошая штука. Я не говорю, что надо общаться высокомерно на «вы», но очень необходимо найти этот предел с каждым подчиненным…

По поводу квалификации руководителя не совсем согласен — она однозначно в его 80% должностных обязанностей должна быть выше подчиненных. Если руководителю приходится кодить (ну бывает так, да) — кодить он должен лучше. Если нет — подчиненные должны понимать что их квалификация как менеджеров на порядок ниже. Т.е. не должно возникать разговоров типа «а хули ты тут с умным видом вещаешь — я тоже могу встать порулить». Как только что-то подобное почувствовали — надо что-то делать, иначе через некоторое время от субординации ничего не останется.

Про ответственность — +1000, поиск виноватых — это всегда шаг назад от возникших трудностей. Васе будет конечно неприятно и обидно, если его назначат виноватым (даже если прямой косяк за ним) но проект это не спасет и убытков не вернет. 98% проблем — прямая или косвенная вина руководителей. Вовремя не заметил, не отследил, подписал неглядя, не проконтролировал, поленился еще раз проверить железо на климат и пр. пр. пр.

Не освещен момент про набор/выбор подчиненных — если это делает ПМ — определяющий всю дальнейшую работу процесс. Месяц-два, без отрыва от текущей работы, с простыми некоммерческими тестовыми заданиями, несколькими беседами и пр. На рынке труда ходит куча дятлов, которые хотят сесть на пригретое место, получать потихоньку оклад, делать видимость работы и придумывать очередные отмазки. Сталкиваюсь лично…

Если вы руководитель без году неделя (ну, год-два), надо всегда помнить, что в этом временном промежутке карьеры отдача падает в разы, а затрат энергии получается в разы же больше — по сравнению с предыдущей областью работы (инженер, кодер). Так вот надо об этом помнить, не пугаться и не отчаиваться. Оно пройдет, как только перейдете на этот новый уровень. Эт правда не мой вывод, это меня так старшие товарищи учат =)
Мне кажется, что для ПМа, не то что разговоры, но даже мысли, о субординации, подчиненных, власти очень опасны :). Заставить кого то делать то, что тебе хочется, приказом или угрозами — это очень очень тяжело. А креативную и творческую личность разработчика — тяжело вдвойне. Я ассоциирую себя в проекте как помощника разработчику — т.е. мы вместе делаем продукт, только просто обязанности и активности разные. Иногда слышу от разработчиков (в шутку надеюсь), что я ничего не делаю в проекте — но трактую это как похвалу, так как «Хорошо сделанная ПМом работа — не заметна» :) Когда разворачивается сражение на поле боя (активная фаза кодирования\разработки в проекте), я стою с биноклем на вершине горы (мания величия???) и смотрю что происходит и не надо ли где нибудь подкорректировать что то, так как моя работа уже сделана — планы атаки согласованы и утверждены, обозы с продовольствием готовы, транспорт заправлен горючим :).
Нуну. В таком случае рад, что у вас пока что-то получается.
она: тебе нравится программировать?
он: да!
она: охренеть…
он: а тебе что ли не нравится?
она: а с чего бы мне нравилось? )
он: ну смотри
int i = 5;
разве это не круто? ты сказала, что в i будет 5 и оно там реально будет. А почему? Потому что ты так сказала! власть!
Тут есть очень тонкая грань, которую переступать нельзя, но вплотную подходить — обязательно. Грань между «что тебе хочется» и «что необходимо делать для успеха проекта».

Если программист отказывается выполнять «недостойную его светлой головы» часть работы, необходимо его убеждать. Сделать всё возможное, чтобы убедить. А если не получится — то вариантов, кроме как надавить. к сожалению, не будет.

Сразу оговорюсь, что при первой возможности от людей, которых невозможно убедить, а можно только заставить, надо избавляться. Второй вариант (причём, гораздо более правильный, на мой взгляд) — понять, что, если я не могу убедить своих людей что-то сделать, то, как руководитель, ценности представляю мало и лучше найти себе другую профессию.
даже если один раз надавить, то потом «светлая голова» сделает за вашей спиной вашу вуду-куклу и будет тыкать в нее иголки когда вы отвернетесь :)
Хороший ПМ таких людей видит и принимает меры, чтобы у них доступа к иголкам не было. А просто куклы — пусть его делает, может хобби у него такое, жалко то ли…
Правильные мысли, поддерживаю.

Я бы еще добавил: объявить своей команде, что каждый может поговорить с руководителем и высказать, что не нравится, как можно улучшить процессы и т.д. без риска «для здоровье» и даже поощрять такие действия подчиненных. Этот ход очень помогает процессу и командообразованию.

Очень правильно это делают в японском менеджменте, где можно поругать своего руководителя и это считается нормой.
У нас в компании демократия :) Я как руководитель ругаю их, а они меня, хотя как правило я больше ругаю и но при этом более добро что ли + так чтобы смешно было :)
Тоже хороший подход! А не замечали какое-то стеснение, когда видно, что человек чем-то не доволен, но не «ругает» вас?
Бывает, нужно пытаться разговорить! Хотя бывает редко, они у меня разговорчивые, уже разговорил :)
Объявлял. Не под торжественные фанфары, конечно, а неявно. Были действительно очень хорошие идеи высказаны ребятами. Принял на вооружение и с успехом пользуюсь.
Если все правильно сделать, от сотрудников можно постоянно идеи получать и улучшать работу. Да и у них будет ощущение вовлеченности, ощущение, что они сами принимают активное участие в построении компании, а это приводит к лояльности, что очень важно.

Я б на вашем месте явно объявил это, все люди разные и могут не сделать, пока не услышат про это прямо, но решать, конечно, только вам :)
я виду цитаты из знакомых книг, какие книги порекомендуете?
Собственно — книг много, но эти три стоит прочитать в первую очередь, ИМХО:

Peopleware (Демарко, Листер) — must read. Плюс — всё, что можно найти у этих авторов
Мифический человеко-месяц (Брукс). Классика, хоть и больше 25 лет книге
Как пасти котов (Рейнвотер) — местами поподает в точку. местами — не очень (по крайней мере, я с ним не везде согласен. Плюс — перевод нудноват)

последние две читал — именно цитаты из них я и узнал. Есть что на замену?
последние две читал — именно цитаты из них я и узнал. Есть что на замену?
Тоже руковожу проектами, и совершенно вас не понимаю. По моему опыту, разрозненная, в идеале находящаяся в разных городах и не общающаяся в отрыве от работы группа разработчиков способна сделать большее, чем слаженная команда.

Потому что последняя всегда склонна принимать неоптимальные решения и страдает от их последствий.

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

Почему само решение, как правило, неоптимально — это я тоже смог понять. Человек, как сказано выше, меньше доверяет одному себе, чем двум соседям. И если кто-то рядом менее компетентный предлагает более простое решение, его понимают больше людей. При этом те люди не понимают более сложную альтернативу — они считают, что ее просто нет (ДК-эффект). В результате коллектив захватывают простые, деструктивные идеи.

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

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

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

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

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

В данных примерах я увидел:
1. Попытку применить излюбленный приём «разделяй и властвуй», при котором происходит манипулятивное управление разными частями грызущихся между собой людей. Этот приём не нов, и его используют сплошь и рядом не только в управлении проектами, но и в политике и т.д. Действительно, раздуть в команде конфликт, играя на противоречиях, гораздо проще, чем добиться авторитета своими действиями и решениями, построив команду, которая считается с вашим мнением.

2. Я вижу руководителя, который не работает (не буду искать причины) с командой. Грамотные вопросы всегда помогают понять людей лучше или указать им на ошибку. Если вы сами не чувствуете себя достаточно технически подкованным — призовите на помощь тимлида из другого отдела. Если с людьми работать, искать варианты и направлять, можно многое сделать. В крайнем случае — да, можно уволить отдельных людей, требующих наибольших ресурсов на «лечение».

3. Затраты на коммуникацию у распределённой команды в разы выше, чем у команды, которая находится в одном месте. Доказано. Брукс.

4. «Коллектив быстро принимает неоптимальное решение и ни в какую не соглашается его изменить, используя в свою защиту всё более глупые аргументы.» — к этому приводит не «соглашательство» и «ДК-эффект», а некорректно построенная работа с командой. Вы можете возразить, что «нянчиться с каждым программистом» — не ваша задача. Я придерживаюсь противоположного мнения.

5. Эксперимент с командами ничего не доказывает. «Профессионализм» команды — вещь достаточно субъективная и не всегда коррелирует с её опытом разработки. Исходя из вашего рассказа, сделаю гипотезу, что во второй команде был человек, который принял на себя роль тимлида, а в первой грамотного лидера не было. Именно поэтому первая команда сплотилась вокруг не слишком компетентного, но харизматичного программиста и ушла в неконструктив. Я прав?
Не правы. Во второй (удаленной) команде я просто раздавал задачи и контролировал их выполнение. Не было ни команды, ни лидера, люди просто делали работу или в рамках своей компетенции объясняли, почему она невозможна. Идеал. Такого, чтобы кто-то говорил «Начальник дурак, он заставил меня делать нереальное, бредовое, давайте саботировать » — такого не было. Зато в первой команде было именно так. Ибо — состоявшийся коллектив. Они немного грызлись, у них недавно ушел старый лидер, но они были абсолютно уверены в своей компетентности, методах и способах. И это при том, что их веб-подразделение никогда не делало ничего прорывного и регулярно срывало сроки.

И я не клал болт на работу. Я знаю про ошибку гиперопеки, что нельзя контролировать каждый шаг и делать всё за других. Первое время я только и делал что объяснял всем и каждому, пока у них не начала появляться гримаса страдания перед каждым таким разговором:) Извините за аналогию, но это было похоже на украинских майданщиков: «мы плевать хотели на мировой опыт, на логику, на законы — у нас своя логика, мы обсудили друг с другом и решили, что так лучше».

Вообще, спасибо человеческое, что попытались вникнуть в мою проблему. Но имхо, примеры тут бессмысленны. Я закончу свой пример, чтобы больше не поднимать эту тему. Решение, которое было выигрышным, заключалосьв том, чтобы программисты-многостаночники освоили Parser-3 (поганую русскую поделку), на котором был написан движок работающего и приносящего доход сайта. Конечно, человек, который это предлагает — мудак и не понимает вещей, тут не может быть другого мнения:)
Слова все правильные, но увы… Пока везде действует железное правило: если руководитель начинает называет возглавляемое им подразделение словом «команда» — то пора валить куда подальше из этой «команды».
На сколько я понимаю, все выше описанное можно уложить в концепцию развития корпоративной культуры.
Другими словами, компания в лице какого-то официального лица должна развивать своих работников с точки зрения внутреннего «морального» облика. Именно для этого в компании принимаются миссия, цель компании, лозунги… Это если говорить про большую компанию и про руководство в ней.
Тем не менее, даже в небольшой компании корпоративная культура играет большую роль в том, чтобы компания из небольшой стало большой. Если маленькой компании суждено выжить, то все, что автор указал как пункты своих размышлений — можно определить как ключевые ценности, пропагандировать всем сотрудникам обращать на внимание и стремиться совершенствоваться.
Я заметил, что очень многие хотели бы дать своему руководству эту статью, или оставили в закладках, чтобы прочитать «когда стану шефом». Мне кажется, не стоит откладывать, а реально предлагать руководству такие мысли и идеи. Ну, или мне повезло с руководством, что есть возможность говорить открыто и развивать открытость как ценность в компании.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории