Комментарии 24
Назначая задачу, нужно убедиться, что человек понял, что от него требуется и что он знает, что нужно делать.
Ваши бы слова да всем тимлидам в уши!
У нас были Software Architect, Project Manager, Product Owner, Test Manager, Quality Manager, Configuration Manager, Scrum Master и два Team Lead’a.
А для чего в одной команде два командных лидера? Чтобы что?
Спасибо, что поделились! Мне всегда казалось, что когда прилетает задача, в которой из описания только заголовок, в ней как будто чего-то не хватает...
Жаль, что часть тимлидов, да и в принципе людей на управленческих ролях, не утруждает себя подробным описанием задачи, а при уточняющих вопросах начинаются упреки в недостаточной квалификации персонала :(
По правилам именования репозиториев и прочих подобных вещах надо не гайдлайны писать, а регулярки в push rules, дабы избежать даже возможности неверных именований и добавления подозрительных файлов. Говоря проще - гайдлайны должны быть не на бумаге, а в автоматизациях.
Видно явное отсутствие у человека какого-либо образования в сфере управления персоналом (курсы повышения квалификации руководителя и т.п.).
Распределение обязанностей и определение ясности поставленной задачи первое чему учат на курсах руководителе, например, курсы по типу "Управление исполнением". Пройдя 3-5 дневный курс можно было избежать большинства представленных проблем.
Кто планирует пробовать себя в качестве руководителя какой-либо группы, да и в целом для общего развития, не поскупитесь на пару курсов в этом направлении.
Если работаете в крупной компании пробуйте встать в резерв кадров на руководящие должности, обучения, чаще всего, включены в подготовку в рамках резерва кадров (компания заплатит за обучение).
Единоначалие должно быть, что значит два тимлида?
У сотрудников должна быть ответственность за выполнение задачи, принимая еë, он должен тем самым давать обратную связь, что все понял, со сроками согласен. Не сделал - ответственность (штраф). "При использовании такого подхода, к концу спринта часть задач была не выполнена т.к люди просто не знали как сделать" - эта проблема должна сниматься в день постановки задачи.
По различным регламентам ("гайдлайны", правила именования или что-то подобное) - аналогично, ответственность исполнителя, отступил от требований - ответственность (штраф).
И главное правило (избитая классика бизнеса) - избавиться от иллюзии, что исполнителям есть дело до судьбы проекта.
1) Мне всё-таки не даётся, что тимлид не начальник, а скорее организатор.
2, 3) Согласен про ответственность, но я не видел явного распространения штрафов в айти индустрии. И очень редко видел, чтобы менеджеры адекватно пользовались штрафами в других сферах. Есть другие средства мотивации и развития чувства ответственности.
4) Разные проекты бывают, опять же, если личная ответственность не мотивирована только штрафами. Соглашусь, что мотивация «мы команд, давайте поднажмем» тоже не работает.
Вы работали в айти командах, где штрафы использовались как средство мотивации? Как это было?
1) как ни назови, но рассчитывать нагрузку, оценивать трудоёмкости и сотрудников, применять меры воздействия (мотивации) должен один человек, в противном случае будут коллизии-конфликты.
Да, приходилось, и в роли тимлида и в роли руководителя организации. Но всё не так однозначно. В моей практике штраф всегда применяется как крайняя мера, реальные штрафы - единичные случаи, хотя в сегодняшней организации сотрудники сами настаивают на введении автоштрафов (но нет) и сейчас попробую объяснить почему.
1. Одна из причин - невозможность формализовать все ситуации для автоматического назначения штрафа, например, та же просрочка, объективно не всегда бывает по вине непосредственного исполнителя, но... в случае если сотрудник своевременно сообщил о проблеме, а не просидел "в ожидании"... и таких "но" великое множество.
2. Почему сотрудники выступают за штрафы - вместо штрафов часто применяется "депремирование", но всей команды - из-за бага, просрочки или по другой нашей вине вовремя не сдаётся этап/работа, заказчик не рассчитывается, заложенные на премирование средства тратятся на дополнительные трудодни для устранения проблемы/"недоделки". В итоге вся команда не получает бонус, и все знают почему (из-за кого). В такой ситуации отлично работает "постановка на вид" на общих собраниях, где констатируется факт - из-за багов/недоделок в таких-то и таких-то модулях проект на этой неделе мы не сдаём или есть предпосылки к просрочке сдачи. И в этой ситуации сотрудники сами настаивают на расширении практики персональных штрафов. Как правило "постановки на вид" с лихвой хватает для мотивации сотрудника увеличить производительность и повысить собственную ответственность к качеству, если этого не хватает, то это уже предпосылка к расставанию, почти всегда штраф - первый шаг к этому.
В итоге вся команда не получает бонус, и все знают почему (из-за кого).
а это не повышает текучку? я бы сразу бы уволился из такой конторы, сразу как такое бы началось, это прямо сирена — о неадекватности руководства
и таких-то модулях проект на этой неделе мы не сдаём или есть предпосылки к просрочке сдачи.
в крупных айтипроектах срывы сроков вообще обычное дело, причем чем крупнее проект и чем больше легаси… да еще если там модномолодежно 'наши сотрудники должны уметь пушить MRы в любой наш репозиторий' то вообще концов не найдёшь чё и кто виноват
вообще ИТ это не та отрасль где штрафы в любом виде работают, а коллективная ответственность — это вообще яд который не работает никогда, вызывает внутреннюю озлобленность в коллективе и снижает производительность
например если васян косячит и мне второй месяц коллективно режут премию — я тоже не буду стараться (премии всёравно не будет), а убеждать васяна — это не моя задача, я вообще программист
"а это не повышает текучку? я бы сразу бы уволился из такой конторы, сразу как такое бы началось, это прямо сирена — о неадекватности руководства"
Нет, не повышает – надо понимать, что бонус, это бонус, а не оговоренная на собеседовании зарплата. Бонус обычно назначается за что-то «сверх» (лояльность, сроки, инициатива, рационализаторство и т.д…) и даже премия «по сдаче в срок» в любом случае не всем автоматом % от зарплаты, а каждому «по заслугам». Если человек считает, что ему априори должны бонус - это прям сирена завершить или не начинать с ним отношения, бегунки - отдельная песня))
"в крупных айтипроектах срывы сроков вообще обычное дело, причем чем крупнее проект и чем больше легаси… да еще если там модномолодежно 'наши сотрудники должны уметь пушить MRы в любой наш репозиторий' то вообще концов не найдёшь чё и кто виноват"
Наладить прозрачную работу и в том числе однозначно для всех знать кто виноват - задача руководства, иначе это не работа, а бардак. По поводу сроков - любой адекватный руководитель всегда закладывает зазор, всё учесть и рассчитать просто невозможно.
"вообще ИТ это не та отрасль где штрафы в любом виде работают," - ИТ такая же отрасль, как и многие другие, люди те же, инстинкты и желания те же, принципы мотивации те же.
"а коллективная ответственность — это вообще яд который не работает никогда, вызывает внутреннюю озлобленность в коллективе и снижает производительность"
это предмет огромного количества споров, публикаций, книг и научных трудов, но в сухом остатке, пока это наиболее эффективный механизм воздействия на группу, хоть непосредственно индивидуумы и против.
"например если васян косячит и мне второй месяц коллективно режут премию — я тоже не буду стараться (премии всёравно не будет), а убеждать васяна — это не моя задача, я вообще программист"
1. ещё раз повторюсь, премию не могут резать, её могут не добавлять. 2. Если из-за Васи 2-й месяц затык, то вопрос к руководству, почему Вася 2 месяца кошмарит проект и до сих пор ещё от него что-то зависит. 3. "это не моя задача, я вообще программист" - подход "моя хата с краю" токсичен для любого коллективного труда).
бегунки — отдельная песня))
а что в вашем понимании бегунок в ИТ сфере?
Наладить прозрачную работу и в том числе однозначно для всех знать кто виноват — задача руководства, иначе это не работа, а бардак.
'У каждой проблемы есть Имя и Фамилия' (с)… ага ага
ИТ такая же отрасль, как и многие другие, люди те же, инстинкты и желания те же, принципы мотивации те же.
да, но в ИТ на рынок труда — рынок работника, а не работодателя, и штрафы и прочие kpi лишь отталкивают нормальных квалифицированных работников. но в целом да. всё также.
Если из-за Васи 2-й месяц затык, то вопрос к руководству, почему Вася 2 месяца кошмарит проект и до сих пор ещё от него что-то зависит.
если у Васи затык, ему надо не премию срезать, а давать помощника или переводить задачу на другого человека… но вы же хотите наказать да?
===
вообще судя по услышанному, я категорически не хочу работать в конторе где вы начальник ;)
«а что в вашем понимании бегунок в ИТ сфере?» - то же, что и в других сферах. Раньше называлось «больной карьеризм». Человек, зацикленный только на росте собственного благосостояния (часто подменяют понятиями «профессиональный рост», «рост скилов» и т.д. и т.п., суть одна, работа только над увеличения собственного вознаграждения) не живёт проектом, не страдает чувством ответственности или совести, такие люди губительны и опасны для любой компании. Характеризуются частыми сменами рабочих мест, отсюда и название «бегунки».
«'У каждой проблемы есть Имя и Фамилия' (с)… ага ага» - да, допускать безответственность сотрудников – глупость и путь в никуда.
«если у Васи затык, ему надо не премию срезать, а давать помощника или переводить задачу на другого человека… но вы же хотите наказать да?» - я вроде не писал, что Васе надо премию срезать, я написал «почему до сих пор ещё от него что-то зависит» - если 2 месяца нерешаемый затык, значит или Вася не на своём месте или просто не хочет работать, в любом случае его просто не должно быть как минимум на этой позиции, а задачу да, переводить на другого человека.
«вообще судя по услышанному, я категорически не хочу работать в конторе где вы начальник ;)» - я думаю мы с Вами не сошлись бы во взглядах ещё на этапе собеседования, или скорее на рассмотрении резюме. У меня есть твёрдое убеждение в том, что сотрудник должен нести ответственность за свою работу, как в плюс, так и в минус.
А если откровенно, то спор ни о чём, у нас разные цели - у любой организации в уставе написано "целью является извлечение прибыли", и любой адекватный руководитель работает с этой целью. У сотрудников разные цели - кто-то хочет профессионального мастерства достичь, кто-то много зарабатывать, кто-то в начальники хочет выбиться, кто-то хочет творить и не трогайте меня, но ни у кого нет цели обеспечить "извлечение прибыли" компании.
Характеризуются частыми сменами рабочих мест, отсюда и название «бегунки».
я меняю работу каждые 3-4 года, я считаюсь бегунком? (вообщето в ИТ отрасли это нормальный срок)
На мой взгляд 3-4 года вполне хороший срок. Такого сотрудника можно привлекать к крупным длительным проектам. Ради интереса посмотрите отклики на вакансии Вашей компании или резюме соискателей на ХХ - не то что раз в год, нередко встречаются индивидуумы меняющие работодателя по несколько раз через 4-8 месяцев.
Я думаю вы (автор темы) не правы в своих выводах и рекомендациях, потому что они уводят от scrum в сторону waterfall. Соответственно скрам тема должна самоорганизовываться на основе живой коммуникации и обратной связи. Этому должны способствовать скрам техники и процедуры. И если в результате них вы приходите к выводу что вам нужно придумать водопад, то значит вы что-то не понимаете в скрам.
Пс. Сказанное выше относится не к вашему конкретно опыту, а к самой идее. Относительно конкретно вашего случая (я тоже участвовал в кроссфункциональных стажировках на geekbrains и тоже сталкивался с тем что вы описываете), то там слишком много хауса чтобы самоорганизоваться за ограниченный период времени, поэтому в принципе ваш вывод для такого случая разделяю. Больше водопада...
Спасибо за комментарий, а можете подробнее про то, что уводит от crum в сторону waterfall? Мы придерживались Scrum во время проекта, то есть были дейли митинги, скрам ретроспективы, планирование и т.д. но хаоса действительно много)
можете подробнее про то, что уводит от crum в сторону waterfall
я не специалист по скрам, поэтому я выражаю лишь как то мной обработанную информацию и впечатление от вашей статьи
поскольку ваш случай с кроссфункциональной стажировкой когда все члены команды одновременно стажируются, то довольно сложно рассуждать о скраме, хотя бы потому спринт предполагает что кто-то берёт задачу и в период спринта не кто его не трогает, он полностью автономен и самостоятелен (в пределах автономности задачи), а тут получается противоречие, потому что изначально ни кто не может ничего особо сделать :)
Тем не менее, я имел ввиду под "уходом к водопаду" попытки прописать и разжевать кто что должен делать в каком порядке в каком виде на каком шаге в виде каких то гайдлайнов, инструкций и прочей "документации". Но это конечно лишь впечатление.
Опыт неопытного тимлида