Про роботу · 13 травня 2017, 12:31 8040

Как менеджерить, если срывают сроки?

Приветики!
Есть я — манагер с 1годом опыта
Есть 2 программиста, мидлы

Есть сроки которые они же озвучивают, но срывают на недели/месяцы. Что делать, что бы оптимизировать работу но и сохранить нормальное общение(это важно)? К их срокам накидывать сверху еще столько же и озвучивать руководству, просить развернуть мониторы ко мне(это ппц конечно) или втф так происходит?

рулю демократично, не борзею, но иногда прошу поовертаймить 2-3 часика вечером.

Как оптимизировать себя и команду?

Пасиб

Теми: менеджмент, сроки

👍ПодобаєтьсяСподобалось0

До обраногоВ обраному0

Facebook

Twitter

Найкращі коментарі пропустити

Beaver Green 13.05.2017 15:53

1) Девелоперы не могут давать эстимейты на недели и тем более месяцы! Задача больше двух дней уже должна разбиваться на части. Если не получается разбить — значит скорее всего задача недостаточно четкая. И это Ваша работа — чем точнее вы сформулируете требования тем больше вероятность получить адекватный эстимейт.
2) Точность эстимейтов зависит от технического долга, качества кода, наличия документации и опыта команды. Если вы взяли двух новых мидлов на «гнилой» проект 5 летней давности то они и одну страницу могут менять месяц — только тронешь Г а там такое полезет...
3) Эстимейты, которые дают девелоперы — это не точное значение, а «пальцем в небо». Поэтому просите два эстимейта: оптимистичный и пессимистичный. И клиенту лучше честно говорите второй (а может еще и от себя умножьте). Частая причина овертаймов и срывов сроков — это менеджер, который «прогнулся» под клиента и пообещал «на вчера».
4) Если девелоперы сами дают эстимейты (без давления!) и сами их потом не выполняют — то это говорит об отношении к работе. Причины может быть две: им не нравится проект или менеджер и они работают «на отвали», или они разгильдяи по-жизни (молодые студенты) которые не умеют отвечать за свои слова.
5) Если команда не мотивирована — то все работают «на отвали» и ждать перфоманса не стоит. Это Ваша задача найти как и чем мотивировать девелоперов (и это не про деньги)! Если причина — херовый проект то Ваша задача найти способ сделать его great again (альтернатива — только закрыть).
6) Если в команде раздолбаи то перевоспитать их тяжело (и стоять над ними с кнутом — бесполезно). Можно или уволить, или найти хоть какое-то применение. Например ввести сдельную оплату: не сделал вовремя — потерял бабки. Если даже такое не поможет — то сэкономите бюджет и сможете нанять еще одного раздолбая что бы двое тянули за одного нормального.
7) Убедитесь что Вы сами подаете пример этузиазма и вовлеченности в проект. Начальник должен овертаймить больше всех! Ну и сами Вы делайте все возможное (давайте девелоперам полные и понятные задачи).
8) Про «нормальное общение» — это изучайте психологию. Менеджер — это как девелопер, только «программировать» нужно людей, а не компы.
9) Ну а если за срыв сроков дрючат Вас — то умение «прикрыть зад» это главный скил менеджера на любом проекте. Не бывает проектов без проблем — поэтому цель не сделать все идеально, а разрулить проблемы так, что бы не остаться виноватым (см. Управление рисками).

Перейти до дискусії

Sergii Donchenko 14.05.2017 16:04

Вам потрібен скрам-мастер.

Перейти до дискусії

O Ch 15.05.2017 13:55

писать можно очень много. но направления я вам дам.

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

Есть я — манагер с 1 годом опыта
Есть 2 программиста, мидлы

Т.е у вас гремучая смесь: джуниор менеджер без опыта + два миддла в самом лучшем случае. В худшем случае, у вас три джуниора в команде. И вы хотите точности.

К их срокам накидывать сверху еще столько же и озвучивать руководству

Это работает в случае, если у вас хорошо работает «чуйка», которая приходит с опытом. Я не раз встречал проблемы с эстимейтами не то чтобы у миддлов, даже у хороших синиоров с опытом. Причем промахи были не просто в два раза, а в 3,4 раза.

Как вы понимаете наверное, накидывать надо на что-то, соотв «накидывание» на в корне неверную основу, приведет просто к большому или огромному увеличению погрешности.

Вы не понимаете кто такие джуниоры\миддлы.
Джуниоры, на то и джуниоры — они в процессе обучения и совершать ошибки во всем — это их привилегия. И миддлы этим страдают не меньше, а иногда даже и больше, просто ошибки миддлов может быть еще сложнее исправить. Они делают ошибки начиная от неверных эстимейтов и заканчивая крупными архитектурными промахами и переписываниями всего, что тянет и раздувает за собой сроки.
И очень плох тот менеджер, который ждет от них точных эстимейтов. Подождите годков 4-5 и точность эстимейтов подрастет. Если, их будет кто-то учить или если они сами очень мотивированы.

Если вам нужно больше предсказуемости, ищите синиоров, архитектов. Только как я понял, из-за очень ограниченных ресурсов, у вас их будет просто некому собеседовать. А в настоящий момент рынок раздут джуниорами или миддлами с лейблами «синиоров», «тим лидов» и «архитектов». Берегитесь их и гоните плеткой, закидывайте их камнями :)

просить развернуть мониторы ко мне(это ппц конечно) или втф так происходит?
рулю демократично, не борзею, но иногда прошу поовертаймить 2-3 часика вечером.

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

Что могу вам порекомендовать

найти сильного с хорошим опытом менеджера. Чтобы поучиться и не наступать на грабли. Изредка процессами могут рулить синиоры, но те кто соображают и стремятся к этому двигаются дальше и растут в СТО, Архитектов и их очень мало.
Научитесь мыслить самостоятельно. Не полагайтесь только на чужое мнение (в данном случае это девы). При планировании итерации, не просто спрашивайте «сколько, а можно быстрее?», принимайте активное участие. Сядьте вместе, опишите то чего вы хотите добиться в конце итерации. Раздробите задачу так сильно, как это можно. Рассмотрите ее вместе с разных точек зрения: и с точки зрения менеджера, продукт оунера, и с точки зрения девелопера. Сколько труда уйдет чтобы сделать кусочек. Вплоть до наброчка черновика того что надо реализовать и его алгоритма. Это поможет не только девам, но и вам самой систематизировать мысли и что нужно
Ну будьте типичным менеджером, коих уже 90% на рынке. В большинстве случаев нужно понимать — на все нужно время. На разработку, тестирование, починку, и на обучение тоже. Больше людей — не лучше. «9 женщин не могут родить одного ребенка за месяц» — почему это вызывает улыбку у всех, но поему-то каждый раз делается одна и та же ошибка: не успеваем -
наймем еще девов. Они все равно не сделают вам задачу на завтра. Ищите проблемы в планировании и менеджменте. Меняйте свои ожидания, избавляейтесь от каши в голове.
Готовьте требования к MVP. в 99% случаев, большая проблема менеджмента — «важно все, деливерим все». Это не правда, если для вас важно все — значит вы просто не в состоянии разобраться в проекте и его бизнес целях. Всегда есть значимые компонены и второстепенные. Всегда есть условия, которыми можно пренебречь в начале, но подготовить почву для них и реализовать потом. Это позволит вам сначала сосредоточиться на наиболее важных вещах, а потом заниматься «свистелками-перделками».
сейчас мейнстрим — SCRUM. вы можете посомтреть в сторону скрама. В него заложены хорошие идеи, НО я предупреждаю сразу, тупое следование книжке — это будет самоубийство в команде без опыта. Более того, даже в команде с опытом, скрам не всегда работает — многое зависит от менталитета команды и отдельных индивидумов в ней. Со скрама я рекомендую вам взять: спринты, груминг, возможно ревью еще. Спринты не делайте большие (неделя — две), учитесь деливерить кусочками. Так вы и сами будете в курсе что и как происходит, и проще будет реагировать на задержки. Вы даже можете поискать себе скрам-мастера, но предупреждаю, в настоящий момент много «обезьян», что имеют недостаточно опыта ни в психологии, ни в менеджменте, ни в скраме в целом. Возможно в вашем случае подойдет выжимка в вотерфола и скрама. но я не могу здесь все расписывать — такие вещи нужно смотреть, общаться с людьми,
понять кто они и что им подходит. Я сказал бы так:
```
не существует идеальных методик управления командой - это всегда индивидуально, это всегда комбинации разных подходов.
 и это всегда требует большой самоотдачи
```
что бы оптимизировать работу но и сохранить нормальное общение(это важно
. На самом деле, хорошо налаженная работа в коллективе — это залог отличного общения.
Я буду резким, НО вы настолько угрузли в том, что вы «Манагер», что забыли — вы всего лишь маленький винтик в системе не стоящий ничего без основания. А основание ваше и ваша опора — это девелоперы. Они фейлят? ок, их уволят в худшем случае. Но может получиться так, что уволят именно вас. Почему? Вы не смогли наладить коммуникации в команде, не справились со своими обязанностями и не смогли деливерить то, что обещали. Более того, скажу как тот, имеет очень много опыта работы и девелопером, и в менеджменте в разных компаниях (и в Украине, и в Европе). Девелоперы, что имеют много опыта, могут достаточно легко подтолкнуть руководство именно к увольнению продукт менеджера, если тот некомпетентен. Я не раз попадал в компании, где были менеджеры, что не представляли с себя ничего, но умели хорошо бить себя пяткой в грудь перед руководством. И крайними всегда оставались девелоперы, стекхолдеры были недовольны. Стекхолдеры это «хавают» какое то время, но так будет не долго. И по опыту скажу, что излечение команды и процессов начиналось со смещения\замены продукт менеджера.

Чтобы быть успешным менеджером, вы должны строить дружную команду, а люди в ней должны быть отвественны за то, что они делают и делать это качественно. Вы можете исповедовать тоталитаризм или демократию — все равно, пока это работает, а команда остается дружной и поддерживает друг друга. Более того, я был в командах, где просто идельано работал именно тоталитаризм, команда работала как часы. В европе например любят демократию, но ничто не мешает проталкивать тоталитаризм под видом демократии или создавать иллюзию демократии. Часто, чтобы навести порядок, нужно аккуратно устраивать тоталитаризм и потом плавно переходить к демократии — там и «скрам» потом подтянется, а если команда заработает как единое целое, то и «канбан» будет.
вы команда, НО все фейлы — это ваша вина, как менеджера. В то же время успех — это достижение команды. Не девелоперы виноваты в этом, ни маркетологи, а вы и только вы. Относитесь к этому так и это сделает вас на голову сильнее. Учитесь принимать на себя весь удар от стекхолдеров и их недовольство в случае фейла. Не ищите крайних — вы крайний. Но всегда делайте вывод. В отдельных и редких случеях имеет смысл погововорить лично и приватно с отдельными девелоперами, но в 99% случаев даже этого не требуется. По личному опыту, стоит принять такую позицию, и команда начинает быстро набирать темп. Во первых они полностью защищены от воздействия стекхолдеров и они это чувствуют, появляется как бы круговая порука, они знают что вам достается если фейлят и что при этом их не делают крайними, но в то же время их достижения как команды могут афишироваться открыто.
научитесь говорить НЕТ стекхолдерам, научитесь говорить себе НЕТ. Очень часто я попадал для налаживания процесса в компании или команды, где продукт менеджеры бегали по струнке перед стехдолдерами, и готовы были ублажать их и реализовывать любой их выпук, независимо от того, что это рушило их планы. Поверьте, реализованный выпук или исправленный текстик стекхолдера удовлетворит на 15 минут в лучшем случае и примется больше как само собой разумеющееся, зато фейл, даже небольшой будут помнить долго. Зарекомендуйте себя у стекхолдеров как довольно жесткого менеджера. Умейте отстаивать и себя и команду. Снова же, здесь понадобится умение расставлять приоритеты.
Защитите команду от себя. Аналогично, часто попадались менеджера с такой кашей в голове, они то и сами не знали что им нужно, а скоуп задачи менялся прямо на глазах. Задачи были не продуманы, напоминали невнятную мешанину. Если в команде нет синиора или лидера, что в состоянии сказать «НЕТ, мы не будем делать эту задачу, просто потому что здесь неточности или непонятности», то вы угрузнете к бесконечных задачах, корректировках и пр. Это вам как менеджеру кажется, что ой, я тут строчечку поменяю в задаче, что уже в прогрессе, и все будет ок. НЕТ, одна строчка может увеличить эстимейты в десятки или сотни раз. Относитесь к задачам и их описаниям как к составлению контракте. По факту, так оно и есть. Считайте что контракт подписан, когда задачу заэстимейтили, и тем более если она уже в спринте или в прогрессе. Не обманывайте себя — любое изменение в последствии — это время, это новый груминг и новый эстимейт.
Если ваши задачи поставлены абстрактно — не удивляйтесь, что вам деливерят не то что вы хотели. как поставили задачу — то и получили. И не полагайтесь на слова. Если не написано — значит не обязательно или не нужно. Записано абстрактно — девелопер волен интерпретировать это как ему захочется и не обижайтесь (но в лучшем случае, он переспросит). Объяснения вроже «Я имела в виду», «я предполагала» и прочие производные не работают.
вникайте в процесс разработки тоже. если нужно — почитайте литературу. пусть вы не будете экспертом, но базовое понимание процесса разработки, методологий вам уж точно не повредит. Не австрагируйтесь от этого. Вам не нужно давать советы девелоперам как делать то или иное, НО понимание процесса поможет направлять разговоры во время митинга и планивания в нужное русло. Я имею очень много опыта в разработке и много лет опыта девелопером, потому во время митинга могу поворачивать разговор в ту сторону, что девелоперы сами принимают те решения, которые нужны были мне: тоталитарная демократия в действии — все довольны. Девелоперы сами принимали решение, а я получил то что нужно.

Перейти до дискусії

Syphilis Candidos 14.05.2017 04:00

Есть 2 программиста, мидлы

Кто сказал что они мидлы? Как мидлы могут грести без синиора? Зачем на двух мидлов целы «манагер»? Вы там лендинги верстаите?

Есть я — манагер с 1годом опыта

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

Перейти до дискусії

Владимир Кожаев 13.05.2017 17:28

1. Срок данный миддлом априори не вызывает доверия. Нужно добавлять в команду как минимум одного синьора.
2. Как оптимизировать работу нельзя сказать — нужно знать больше: что за проект, что за люди, почему надо быстрее?