Pull to refresh

Comments 5

"Что мешает работать в команде?"

1. Отсутствие самой команды, т.к. это может быть не команда, а всего сборище токсичных "индивидуальностей".

2. KPI, где больше ценится индивидуальный вклад, чем командная работа. Например, увольнять 10% самых медленных сотрудников каждый год, что ранее практиковала Microsoft и некоторые другие западные компании.

3. Наличие в команде родственников директора или ТОП-менеджеров, а также всяких «шпионов», которые при первой же возможности донесут наверх новости о твои «косяках» в работе.  

4. Для новичков — это отсутствие онбординга и знакомства с командой.   

4. Для новичков — это отсутствие онбординга и знакомства с командой.   

За это вот вообще люто плюсую.
Лично за последний год сталкиваюсь с тем, что прихожу в компанию, на собесе говорят, что вот это всё есть, а на деле - ничего.
В одной компании с направлением в кибербезопастность вообще было чуть ли не смешно.
Заранее предупредил компанию, когда приду, но в итоге всё настраивал себе сам и никто и не знал в офисе, что я приду.
Когда начал рукодителя непосредственного дергать, то начал слышать всё чаще "это к HR". HRBP чуть ли не через день начал спрашивать "Что там с онбордингом и адаптацией?"
В итоге, не дождавшись действий ни от руководства, ни от HR , ушёл. Так мне HR ещё как масла в огонь сказала : "Это всё из-за того, что HR нет в вашем офисе. Был бы в Москве, то было бы всё". Ну да, ну да.

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

Чтобы этого всего не было, нужен нормальный тимлид и нормальный проджект менеджер (скрам-мастер). Кстати, в маленькой команде эти задачи может совмещать и один человек. Собрал, выслушал всех по поводу темы, потом сказал, используем вот эту и всё. То же самое с задачами: чтобы не было такого, что кто-то набрал себе задач, а другим не осталось, нужно брать разработчиков на планирование спринта. Перед назначением задачи уточнять, согласен ли разработчик с эстимэйтом. А те задачи, которые никому не нравятся, распределять в приказном порядке.

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

Sign up to leave a comment.

Articles