На своем опыте скажу, что тут или стагнация, как описал автор, или владелец находит инвестиции на реализацию качественного продукта, тем более, что MVPшкой гипотезы проверили, для инвесторов информация есть. то есть следующие шаги по статье это
оценить беклог, включая техдолг,
приоритизировать
понять кого берем
набрать
при этом надо четко понимать, что набор даже сильного разработчика вначале время разработки замедлит: он будет разбираться в том, что есть (док то нет) и дергать старичков. (правда если небольшое MVP, недолго)
Все это должно быть спланировано и запихнуто в план работ/финплан и так далее.
В ИТ интеграторах (я разных видел) структура от бригадной (на каждый продукт своя команда, при общих бухгалтерии, юристах) к сильной матрице. То есть с ростом компании приходится делиться на отделы (аналитики, разработчики, тестировщики), но они сами по себе смысла не имеют, деньги зарабатываются проектами, потому руководят командой РПшники.
Один из заказчиков, большое предприятие, оказывающее коммунальные услуги, который в последнее время был у меня на глазах, болтается где то между классической матрицей и дивизионной структурой (достаточно независимые филиалы со своим hr бухгалтерией, но часть функций, к примеру юристы и судебные дела только через центральный офис)
Теперь про проектные офисы. В заказчике из п2 выше у них болтанка: они уходят от Матрицы-пф и идут к матрице ГС, видимо.
я не соглашусь про задницу :) эта задача , разумеется, есть, но она - вторая.
первая задача - все таки решить вопрос и пихнуть проект дальше. Ничего личного, это просто наша работа.
С админом история для меня такая (и, я считаю, так РП и должен работать): я к любому человеку в команде отношусь с уважением. К внешникам, как в примере - также. Я понимаю, что люди заняты и именно поэтому я готов приехать сам, лично, в любое удобное время, пояснить, что и зачем надо, чтобы решить это быстро, не занимая много времени. Могу не приезжать, а просто созвониться, как удобнее. Я понимаю, что у человека много дел, но мне дали именно его, и никого другого. Если он занят, я схожу к руководителю и расскажу, что человек занят, это не проблема. Если дадут все равно его, я опять приду к нему :)
Действительно, есть много компаний, где люди перегружены из-за проблем с персоналом. Есть и другие случаи (я лично сталкивался несколько раз), когда у эксперта врубается "синдром вахтера" и он откровенно начинает "тренировать" РП. В целом, это должно быть неважно. Уважение и настойчивость открывают двери :)
тут есть определённый баланс. Можно просто спихивать в стиле чайка-менеджмента, тогда это будет без уважения. А где нет уважения - нет хороших отношений.
Я стараюсь всегда приходить с объяснением что , как и почему это важно. Именно поэтому я написал, что мне не лень поднять попу и доехать, поговорить, а не просто написать. Это - жест уважения. Если человек это не ценит или приоритеты другие - есть план Б. Если ценит - мы всегда договариваемся. И в следующий раз все описанные шаги уже не нужны, я просто звоню и вопрос решается за 5-10 мин, по братски)
моя идея в том, что хороший руководитель и правда должен быть помощником для команды и помогать тем, кому надо. Не все и не всегда видят свои слепые зоны. Часто не получается понять, что я чего то не понимаю, пока я этого не пойму. А это должен кто-то объяснить и показать. И статья про это есть вот эта: https://habr.com/ru/articles/839304/ (отношения руководителя проектов и его команды).
Суть этой статьи, что это все не отменяет ответственности за самого себя.
я согласен про незаменимых людей, это обязательно нужно делать, если такая возможность есть. В статье речь как раз про ситуации, когда избавится от такого человека РП не может. Очень часто на проекте есть согласованты со стороны заказчика, со стороны бизнеса или ИТ, которые не подчиняются РП никак. Просто РП говорят: пойди и согласуй инфраструктуру в ИТ отделе. А там сидит админ в режиме "я одна, а вас много" и ему этот РП вообще нафиг не нужен, у него и так реально 100 дел одновременно и РП - 101ое.
Избавится от таких людей РП не может - он не функциональный руководитель.
И надо учиться договариваться в такой среде. Статья про то, как это делать не ссорясь, а вежливо отставая свои границы в рамках приоритетов самой компании.
ну я бы добавил - не делать это только один раз. А делать несколько раз. Быть вежливым, но настойчивым дятлом, который долбит.
Один раз попросил эксперта помочь, а он не смог - старшие руководители всегда представят так, что эксперт был занят (у него же много дел), а РП не добился результата.
А если РП пришел несколько раз, эскалировал несколько раз, а все забили... Ну что тут еще сделаешь, реально?
Это и есть передача ответственности другим людям: я делаю все, что могу, я подтверждаю это фактурой, и в этот момент другой человек понимает, что крайним совершенно обоснованно становится он и спихнуть ответственность с себя уже не получается.
И внезапно он становится сговорчивым, с большим желанием помогать. И время находится и желание. Надо же :)
Без амбициозности не захватываются новые рынки, аккаунты и так далее.
К примеру, я знаю случай, когда заказчик попросил оценить объем работ по созданию CRM системы одного подрядчика, и тот попросил 3 месяца на оценку работ.
За это время второй, небольшой но амбициозный подрядчик сделал не просто оценку, а развернул CRM, автоматизировал там пару процессов и сделал это все на основании интервью с будущими пользователями на местах.
В итоге он и взял все работы по этому домену, который успешно развивает уже 6 лет.
Да, это были 2 месяца переработок пары сотрудников, да, пришлось поднять попу и поехать по филиалам заказчика к пользователям, да, два года после этого разработчики рефакторили последствия того, что тогда было сделано тяп-ляп. Но это было быстро.
Кто голоднее, тот быстрее, и тот выигрывает, при прочих равных.
Это и есть проблема крупных компаний, они перестают идти на риск, считая его неоправданным.
Тут очень легко скатиться в другую крайность: сотрудники очень быстро понимают, что можно самим не думать, а пойти к руководителю, он все разрулит. Это классная позиция для сотрудника и проигрышная - для руководителя.
Такие истории для него всегда заканчиваются тем, что он становится бутылочным горлышком в коммуникациях, потому что решает проблемы всех своих обленившихся сотрудников и физически не успевает выполнять свои обязанности.
У Славы Панкратова только что увидел классное видео про "менеджера снежинку", который не умеет делегировать ответственность и очень быстро умирает.
За последний год на последнем рабочем месте очень активно использовали аутстафф, так как требовалось быстро растить команду.
Никакие метрики я не смотрел, рейтинг Рунета не смотрел, ввел в Яндексе "аутстафф разработчики /язык/", выбрал первые три строчки в поиске (не рекламные и написал всем троим.
Отреагировали двое сразу, одни - через сутки.
И только одна компания смогла быстро закрыть все вакансии и активно помогала на протяжении всего года.
Мой вывод прост: главное - качество клиентского сервиса со стороны аутстаффа. Быстро отвечать, быть заинтересованным, стараться реально закрывать потребности клиента, быстро давать качественных кандидатов под описание позиции, не продавать джунов под видом миддлов (а многие это любят), уметь гибко забирать сотрудников назад, обладать всем специалистами: BA, SA, dev, QA. DevOps нам был не нужен, так что не могу сказать по необходимости). Кто это делает - тот молодец
Вы знаете, у меня другая выборка. Последние 10 лет и 5 мест работы моя обратная связь отлично работает. Да, я ушел из пары мест, так как не вышло договориться по критичным вопросам. Но это произошло честно и открыто. Это не значит, что обратка не работает, это значит, что когда я даю обратку, у другого человека может быть другое мнение. Это нормально. Просто дальше я с этим или согласен и остаюсь или ухожу.
Удивительно при этом, что честная обратка много раз позволила сохранить хорошие отношения, в отличие от тихих и молчаливых переходов.
Вопросы психологии отношений крайне субъективны, тут у каждого есть свой личный опыт. Вплоть до того, верить в то, что стакан наполовину полон или наполовину пуст.
Мой личный опыт в том, что я ставил границы именно так, как описал выше и меня просили написать заявление по собственному. И я ни секунды не пожалел, что написал. Зато я не работал с теми, кому пофиг на вещи, которые для меня критичны. Рынок сейчас достаточно большой и выбор, с кем работать есть. Благодаря этому алгоритму последние 10 лет я работаю именно там, где мне нравится.
как и первая статья, отлично расписана общая методология работы с ИТ проектом.
есть пара моментов, которые вызывают вопросы:
Название статьи: если заказчик лезет в управление проектом, то заказчик обычно покупает аутстафф разработку, оставляя аналитику и менеджмент за собой. И менеджер заказчика должен знать все вышеперечиленное. Если заказчик не лезет в микроменеджмент, ему пофигу на нашу ИТ кухню, ему важно чтобы мы сделаи в сроки и в бюджет. Все.
Любая методология ведения проекта зависит от размера проекта. К примеру, на проекте по созданию корпсайта на 3 мес и 3х разработчиков делать матрицу рисков и план коммуникаций, как правило, смысла нет.
ну и, кстати, сейчас все работают гибридом, разделяя вотерфольный проект на спринты разработки. Это важный момент, про который я бы тоже упомянул.
статья очень короткая и из поста автора ясно, что после того, как был дан негативный фидбек, к нему приходил руководитель и разговор был. Что случилось на том разговоре и что спрашивал руководитель - неясно, информация здесь только от работника.
то, что HR не в курсе непродления контракта - это непрофессионализм линейного менеджера и плохая связка HR-производство в компании. Это - непрофессиональная работа, это факт. Такого быть не должно ни при каких раскладах.
автору поста и всем, кто советует врать на 360. Есть разные стратегии поведения от суперчестности до 100% вранья, я пробовал их все. И хочу сказать, что обе крайности (честно в лицо СЕО говорить, что он не прав или вообще ничего не говорить) работают плохо. В любых отношениях нужно учиться тактично говорить о том, что не устраивает. Это касается и работы, и дружбы и влюбленности - тут без разницы.
А дальше получится тот результат, что получится. В случае автора я рад за него, потому что он не будет работать с непрофессионалами (см п 2). Но и автору есть , куда расти. Короче, всем в этой истории хорошо.
На своем опыте скажу, что тут или стагнация, как описал автор, или владелец находит инвестиции на реализацию качественного продукта, тем более, что MVPшкой гипотезы проверили, для инвесторов информация есть. то есть следующие шаги по статье это
оценить беклог, включая техдолг,
приоритизировать
понять кого берем
набрать
при этом надо четко понимать, что набор даже сильного разработчика вначале время разработки замедлит: он будет разбираться в том, что есть (док то нет) и дергать старичков. (правда если небольшое MVP, недолго)
Все это должно быть спланировано и запихнуто в план работ/финплан и так далее.
Чтобы ответить, пришлось перечитать еще раз :)
по оргструктуре:
В ИТ интеграторах (я разных видел) структура от бригадной (на каждый продукт своя команда, при общих бухгалтерии, юристах) к сильной матрице. То есть с ростом компании приходится делиться на отделы (аналитики, разработчики, тестировщики), но они сами по себе смысла не имеют, деньги зарабатываются проектами, потому руководят командой РПшники.
Один из заказчиков, большое предприятие, оказывающее коммунальные услуги, который в последнее время был у меня на глазах, болтается где то между классической матрицей и дивизионной структурой (достаточно независимые филиалы со своим hr бухгалтерией, но часть функций, к примеру юристы и судебные дела только через центральный офис)
Теперь про проектные офисы. В заказчике из п2 выше у них болтанка: они уходят от Матрицы-пф и идут к матрице ГС, видимо.
все хотят сказку с хорошим концом. особенно хотят взрослые, даже руководители больших компаний, даже школьные учителя. Осознанных вообще мало, увы
я не соглашусь про задницу :) эта задача , разумеется, есть, но она - вторая.
первая задача - все таки решить вопрос и пихнуть проект дальше. Ничего личного, это просто наша работа.
С админом история для меня такая (и, я считаю, так РП и должен работать): я к любому человеку в команде отношусь с уважением. К внешникам, как в примере - также. Я понимаю, что люди заняты и именно поэтому я готов приехать сам, лично, в любое удобное время, пояснить, что и зачем надо, чтобы решить это быстро, не занимая много времени. Могу не приезжать, а просто созвониться, как удобнее. Я понимаю, что у человека много дел, но мне дали именно его, и никого другого. Если он занят, я схожу к руководителю и расскажу, что человек занят, это не проблема. Если дадут все равно его, я опять приду к нему :)
Действительно, есть много компаний, где люди перегружены из-за проблем с персоналом. Есть и другие случаи (я лично сталкивался несколько раз), когда у эксперта врубается "синдром вахтера" и он откровенно начинает "тренировать" РП. В целом, это должно быть неважно. Уважение и настойчивость открывают двери :)
100% да. вот статья как раз для тех, кто боится. Я сам долго учился этой аккуратной настойчивости и вижу, что новеньким ее не хватает.
Пусть учатся)
тут есть определённый баланс. Можно просто спихивать в стиле чайка-менеджмента, тогда это будет без уважения. А где нет уважения - нет хороших отношений.
Я стараюсь всегда приходить с объяснением что , как и почему это важно. Именно поэтому я написал, что мне не лень поднять попу и доехать, поговорить, а не просто написать. Это - жест уважения. Если человек это не ценит или приоритеты другие - есть план Б. Если ценит - мы всегда договариваемся. И в следующий раз все описанные шаги уже не нужны, я просто звоню и вопрос решается за 5-10 мин, по братски)
моя идея в том, что хороший руководитель и правда должен быть помощником для команды и помогать тем, кому надо. Не все и не всегда видят свои слепые зоны. Часто не получается понять, что я чего то не понимаю, пока я этого не пойму. А это должен кто-то объяснить и показать. И статья про это есть вот эта: https://habr.com/ru/articles/839304/ (отношения руководителя проектов и его команды).
Суть этой статьи, что это все не отменяет ответственности за самого себя.
Именно. И РП говорят, что он должен был найти способ договориться. Именно такой способ и описан в статье.
я согласен про незаменимых людей, это обязательно нужно делать, если такая возможность есть. В статье речь как раз про ситуации, когда избавится от такого человека РП не может. Очень часто на проекте есть согласованты со стороны заказчика, со стороны бизнеса или ИТ, которые не подчиняются РП никак. Просто РП говорят: пойди и согласуй инфраструктуру в ИТ отделе. А там сидит админ в режиме "я одна, а вас много" и ему этот РП вообще нафиг не нужен, у него и так реально 100 дел одновременно и РП - 101ое.
Избавится от таких людей РП не может - он не функциональный руководитель.
И надо учиться договариваться в такой среде. Статья про то, как это делать не ссорясь, а вежливо отставая свои границы в рамках приоритетов самой компании.
ну я бы добавил - не делать это только один раз. А делать несколько раз. Быть вежливым, но настойчивым дятлом, который долбит.
Один раз попросил эксперта помочь, а он не смог - старшие руководители всегда представят так, что эксперт был занят (у него же много дел), а РП не добился результата.
А если РП пришел несколько раз, эскалировал несколько раз, а все забили... Ну что тут еще сделаешь, реально?
абсолютно точно, согласен на 100%.
Это и есть передача ответственности другим людям: я делаю все, что могу, я подтверждаю это фактурой, и в этот момент другой человек понимает, что крайним совершенно обоснованно становится он и спихнуть ответственность с себя уже не получается.
И внезапно он становится сговорчивым, с большим желанием помогать. И время находится и желание. Надо же :)
нет , конечно) аутстафф - конкурентный бизнес, волка ноги кормят :)
да, мы много пробовали различных компаний. И тут срабатывает общее правило: тот, кто дает качественный сервис - выигрывает.
Без амбициозности не захватываются новые рынки, аккаунты и так далее.
К примеру, я знаю случай, когда заказчик попросил оценить объем работ по созданию CRM системы одного подрядчика, и тот попросил 3 месяца на оценку работ.
За это время второй, небольшой но амбициозный подрядчик сделал не просто оценку, а развернул CRM, автоматизировал там пару процессов и сделал это все на основании интервью с будущими пользователями на местах.
В итоге он и взял все работы по этому домену, который успешно развивает уже 6 лет.
Да, это были 2 месяца переработок пары сотрудников, да, пришлось поднять попу и поехать по филиалам заказчика к пользователям, да, два года после этого разработчики рефакторили последствия того, что тогда было сделано тяп-ляп. Но это было быстро.
Кто голоднее, тот быстрее, и тот выигрывает, при прочих равных.
Это и есть проблема крупных компаний, они перестают идти на риск, считая его неоправданным.
Тут очень легко скатиться в другую крайность: сотрудники очень быстро понимают, что можно самим не думать, а пойти к руководителю, он все разрулит. Это классная позиция для сотрудника и проигрышная - для руководителя.
Такие истории для него всегда заканчиваются тем, что он становится бутылочным горлышком в коммуникациях, потому что решает проблемы всех своих обленившихся сотрудников и физически не успевает выполнять свои обязанности.
У Славы Панкратова только что увидел классное видео про "менеджера снежинку", который не умеет делегировать ответственность и очень быстро умирает.
За последний год на последнем рабочем месте очень активно использовали аутстафф, так как требовалось быстро растить команду.
Никакие метрики я не смотрел, рейтинг Рунета не смотрел, ввел в Яндексе "аутстафф разработчики /язык/", выбрал первые три строчки в поиске (не рекламные и написал всем троим.
Отреагировали двое сразу, одни - через сутки.
И только одна компания смогла быстро закрыть все вакансии и активно помогала на протяжении всего года.
Мой вывод прост: главное - качество клиентского сервиса со стороны аутстаффа. Быстро отвечать, быть заинтересованным, стараться реально закрывать потребности клиента, быстро давать качественных кандидатов под описание позиции, не продавать джунов под видом миддлов (а многие это любят), уметь гибко забирать сотрудников назад, обладать всем специалистами: BA, SA, dev, QA. DevOps нам был не нужен, так что не могу сказать по необходимости). Кто это делает - тот молодец
Софтскиллы тоже сами по себе не появляются, это не харды, оно по книжкам не изучается.
Статья написана потому, что я вижу вокруг себя значительное количество людей, которые не умеют говорить с руководителем о своих потребностях.
Как руководитель, я своей команде втолковывал это последние несколько лет и то, получилось не до конца.
Метод в статье позволяет начать говорить о себе. Он неидеален, там есть нюансы, но 90% сотрудников стоило бы реально просто начать говорить о себе.
Я написал статью как раз из-за этих 99%.
Вы знаете, у меня другая выборка. Последние 10 лет и 5 мест работы моя обратная связь отлично работает. Да, я ушел из пары мест, так как не вышло договориться по критичным вопросам. Но это произошло честно и открыто. Это не значит, что обратка не работает, это значит, что когда я даю обратку, у другого человека может быть другое мнение. Это нормально. Просто дальше я с этим или согласен и остаюсь или ухожу.
Удивительно при этом, что честная обратка много раз позволила сохранить хорошие отношения, в отличие от тихих и молчаливых переходов.
Вопросы психологии отношений крайне субъективны, тут у каждого есть свой личный опыт. Вплоть до того, верить в то, что стакан наполовину полон или наполовину пуст.
Мой личный опыт в том, что я ставил границы именно так, как описал выше и меня просили написать заявление по собственному. И я ни секунды не пожалел, что написал. Зато я не работал с теми, кому пофиг на вещи, которые для меня критичны. Рынок сейчас достаточно большой и выбор, с кем работать есть. Благодаря этому алгоритму последние 10 лет я работаю именно там, где мне нравится.
Этим я и хотел поделиться.
как и первая статья, отлично расписана общая методология работы с ИТ проектом.
есть пара моментов, которые вызывают вопросы:
Название статьи: если заказчик лезет в управление проектом, то заказчик обычно покупает аутстафф разработку, оставляя аналитику и менеджмент за собой. И менеджер заказчика должен знать все вышеперечиленное. Если заказчик не лезет в микроменеджмент, ему пофигу на нашу ИТ кухню, ему важно чтобы мы сделаи в сроки и в бюджет. Все.
Любая методология ведения проекта зависит от размера проекта. К примеру, на проекте по созданию корпсайта на 3 мес и 3х разработчиков делать матрицу рисков и план коммуникаций, как правило, смысла нет.
ну и, кстати, сейчас все работают гибридом, разделяя вотерфольный проект на спринты разработки. Это важный момент, про который я бы тоже упомянул.
Я выскажусь, как руководитель производства.
статья очень короткая и из поста автора ясно, что после того, как был дан негативный фидбек, к нему приходил руководитель и разговор был. Что случилось на том разговоре и что спрашивал руководитель - неясно, информация здесь только от работника.
то, что HR не в курсе непродления контракта - это непрофессионализм линейного менеджера и плохая связка HR-производство в компании. Это - непрофессиональная работа, это факт. Такого быть не должно ни при каких раскладах.
автору поста и всем, кто советует врать на 360. Есть разные стратегии поведения от суперчестности до 100% вранья, я пробовал их все. И хочу сказать, что обе крайности (честно в лицо СЕО говорить, что он не прав или вообще ничего не говорить) работают плохо. В любых отношениях нужно учиться тактично говорить о том, что не устраивает. Это касается и работы, и дружбы и влюбленности - тут без разницы.
А дальше получится тот результат, что получится. В случае автора я рад за него, потому что он не будет работать с непрофессионалами (см п 2). Но и автору есть , куда расти. Короче, всем в этой истории хорошо.