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

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

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

Причина была прозаична - ПО набрался крутого опыта, а зп и погоны не поспевали, поэтому просто-напросто перекупили. Это американский рынок, там такое сплошь и рядом. И двух-недельное уведомление - это нам ещё повезло, обычно за неделю люди увольняются.

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

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

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

То, что всех бесит ссылка на телеграм канал в конце поста, это не повод ставить её в самом начале.

Право слово, вы меня недооцениваете, я и в начале впихнул и в конце. 😅

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

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

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

Большое спасибо за статью! Очень познавательно:)

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

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

В двух словах - порешали через начальство.

"Порешали" - это незаконченная форма. Порешали что-то, не решили и оставили как есть. А тут решили.

Порешали большинство проблем...

Это всё равно значит, что позанимались ими и не решили. Правильно говорить решили.

"Решили" это раз и навсегда, а "порешали" это решили те задачии вопросы, что накопились с ожиданием новых в будущем.

Нет. Учите язык.

Новый руководитель продукта упарывается в микроменеджмент – любой чих в бэклоге должен быть с ним согласован

Таких шизиков вообще к управлению людьми допускать нельзя.

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

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

НЛО прилетело и опубликовало эту надпись здесь

Не пытайтесь найти чёрную кошку в тёмной комнате особенно когда её нет. Логично, что мы пытались предложить ПО со своей стороны: сначала увольняется прежний ПО, команда месяц или два "курит бамбук". Там весь процесс найма занял около 3х месяцев, может чуть больше.

А насчёт зарплата поинтереснее... Вы наверное мало знакомы с финансовой частью аутсорса. Тут есть нюанс, у нас есть стандартная рейт карта, где прописано, что руководитель продукта стоит столько-то в час и рейт-карта для Восточной Европы НАМНОГО дешевле чем для US. За сколько нового ПО в конечном итоге наняли - мне не ведомо, да и не интересовался я.
А про саботаж, это вообще пять. :)

НЛО прилетело и опубликовало эту надпись здесь

Хммм. Вам либо очень хочется похоливарить, либо вы очень не шарите за то как работает аутсорс. Штош.

Вы какую-то фантастику рассказываете, человек ушёл и всё развалилось. Так не бывает, тем более что у вас там кто-то выше был.

Есть такая штука как roadmap, она была у команды на полгода, на основании карты работ был составлен бэклог на несколько месяцев. А ещё есть проблема трафика в формировании бэклога, можете видосик посмотреть, там для машинок, но аналогия ясна и понятна - The Simple Solution to Traffic (youtube.com) А если начать придираться к словам - у команды бизнес-аналитиков упала производительность, потому что они должны переводить требования от бизнеса в понятный язык для разработчиков, а требования от бизнеса собирает руководитель продукта. Звено в цепочке вывалилось и начинаются проблемы. Я конечно понимаю, что можно героически их потом решать, но я лучше заранее мозг выем чайной ложечкой, но проблемы упрежу заранее. Поэтому поиск кандидата на роль руководителя продукта, а затем его адаптация - и через полгода могли бы быть проблемы о которых вы говорите, но только у всей команды.

Вы их по месту рождения метите? Что мешает переехать человеку из восточной европы и внезапно получать больше? Может конечно у вас какой-нибудь sweatshop и за еду работают, но в последние годы рейт был вполне сопоставим хоть из восточной, хоть из западной. Ну может на десятки процентов ниже, но не в разы. Тем более человеку же не абсолютные цифры были интересны, а относительные. Например получал Х, а новая позиция ему обещала 1.5Х, достаточная мотивация чтобы чуток в политические игры поиграть.

Ок, перефразирую, тк даже на уровне википедии списки стран Восточной и Центральной Европы сильно пересекаются. Первоначально я имел ввиду РБ, РФ, Украину. Надеюсь это поможет для дальнейшего диалога. Как назвать этот регион правильно - я не знаю - ОЧЕНЬ ВОСТОЧНАЯ ЕВРОПА подойдет? XD

Поэтому двигаем дальше.

Например мешает контракт и налоги в разных странах, так же статистика - если вы утрудите себя и посмотрите в тот же glassdoor, то обнаружите, что разработчик в Очень Восточной Европе может получать БОЛЬШЕ чем например в Западной, но есть нюанс - налоги. И если в РБ и РФ были созданы налоговые льготы (про Украину с её ИП я вообще молчу), то в остальной Европе налоговых льгот нет и компаниям приходится платить значительно больше. Финальная стоимость же для заказчика складывается из зп сотрудника + накладные затраты в виде местных налогов (как минимум). Но это валидно для аутсорса, у продуктовых компаний и стартапов свои правила игры.
Притом если вы внимательно почитаете текст, то увидите, что руководителя продукта наняли в США. А зп в США(+ налоги) намного выше чем в Европе. Опять же glassdoor в помощь.

И возвращаясь к теме контракта - если человек переезжает в другую страну, полностью меняется его финансовая компенсация(и далеко не факт, что становится выше в рамках чистой прибыли), но и меняются накладные расходы на сотрудника, поэтому заказчик в рамках контракта может отказаться от такого сотрудника - он становится слишком дорог. И переезд в США - не всегда простая, быстрая, а главное дешёвая задача.

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

Ну судя по вашим рассказам, что из-за проблем с бэклогом не было фронта работ. Это очень интересные рассказы. Вы из этих 30 человек половину на бенч садили? Или клиент платил, а они воздух пинали? Кроме прям явного саботажа, бывает и какая-нибудь итальянская забастовка, тоже вполне себе саботаж.

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

Возможно у вас есть личный бэкграунд, не знаю правда какой он и вы пытаетесь его переложить на мой пример, но не работает. ¯\_(ツ)_/¯

засунуть в лютый стафог

Не поясните, что такое "стафог"? А то по контексту я боюсь даже предположить.

Стафог, калька с английского StaffAug (staff augmentation) говоря упрощённо этакий продвинутый бодишоп: "дайте нам десять землекопов, которые умеют копать". Хотя в нашем случае это был уже PES, но в данном примере особого значения это не играет.

Минутка рекламы: я в своём ТГ сейчас пишу про историю развития аутсоср индустрии, вот первая заметка - https://t.me/notesoncuffs/55 там как раз рассказывается про стафог, его плюсы и минусы.

А что такое PES? 😄

Есть такие очень умные ребятки которые занимаются анализом айтишнего рынка - Forrester (их аналитические доклады стоят шибко дорого, однако), они в своё время много-много лет назад разработали, а может быть просто запротоколировали такие направления в развитии аутсорса как PDS - product development services, PES - product engineering services. Я о них позже статьи напишу. Там с точки зрения ответственности/денег очень интересно получается.

А так есть ещё и @pes_loxmaty. 🤣

Хороший лингвистическо-психологический трюк. Похоже на такой феномен: если ответить человеку на просьбу отремонтировать компьютер: "Нет, твой ПК я ремонтировать не буду", - он обидится / будет настаивать. А если сказать "я не ремонтирую ПК", то и чел. не обидится (не именно его отшивают), и придраться не к чему (он просто пришёл не по адресу).

К сожалению не для нас, мы к тому времени уже "спалились", что умеем чинить ПК. :)

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

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

И у меня бы сразу были бы вопросы к тому, кто так нанимает новых сотрудников рискуя похоронить весь свой бизнес.
Честно говоря я бы свалил сразу после появления вот такого кадра )

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории