2020-07-29 10:59:25
Думаю, вы видели неэффективные команды. Люди работают, что-то вроде делается, а вяло как-то. И неважно, большая это команда или маленькая.
И встречали эффективные команды. Вроде и сотрудников немного, а проекты делают масштабные и крутые.
Я сейчас руковожу маленькой, но гордой командой разработчиков. И я заметил интересный нюанс - вещи, которые я как мы думал будем делать неделями, мы делаем за дни. Ну то есть быстрее получается, чем планировалось.
С одной стороны, это моя нехватка опыта пока не позволяет оценивать сроки с достаточной точностью. Но с другой стороны, я и команда совершенно точно стали быстрее работать, чем два или три месяца назад, когда мы были просто разрозненными разработчиками.
Я начал задумываться, почему так - что делаем иначе? И пришел к следующим выводам.
Нужен план. Я и команда должны знать, куда мы сейчас идем, на какой стадии находимся. Как именно мы будем захватывать мир.
План - это идея, это маяк. Мы можем где-то по мелочам что-то не понимать. Но когда мы все знаем, куда идем - мы сможем нормально оценивать важность и нужность задач. Если задача как-то ведет к реализации плана, возможно и в долгосрочной перспективе - это хорошая задача.
План можно и нужно корректировать. Но он должен быть. Моя задача - убедиться, что вся команда знает этот план.
Нужны четкие понятные задачи. Это не значит легкие. Это не значит, что задачу можно сделать за час или даже за день. Но каждому разработчику должно быть понятно, чем он сейчас занимается, для чего он это делает, и какую пользу он принесет, сделав эту задачу. Должны быть понятные критерии выполненности задачи.
Обратный пример, когда мы не знаем что и для чего делаем, демотивирует. Складывается ощущение бесполезности работы.
Когда я стал руководить группой, я выделяю каждый день блок времени, чтобы оценить текущее состояние, выделить проблемные места, и подумать, кому что нужно сегодня делать. Дальше мы созваниваемся группой, и проговариваем эти задачи.
Часто на каждый день большинство людей знает, чем заниматься. Достаточно услышать их, и слегка подкорректировать задачи.
Лучше больше задач, чем меньше. Если у меня, у другого сотрудника есть много разных задач, но каждая из которых решаемая и понятная - это хорошо. Это в разы лучше, чем когда разработчик пофиксит баг, сделает задачку, и не будет знать, что делать дальше.
У меня уже было два случая, когда разные люди писал мне "все сделал уже, что делать дальше". Считаю это тревожным звоночком для себя - значит, я недостаточно далеко заглянул вперед, и команда недогружена задачами. Теперь я задумываюсь чуть дальше - "вот сделаем мы это, а дальше?". Это частично работа PM, но и моя тоже.
Загруженный задачами разработчик прекрасен. Я за то, чтобы в 18 вечера, или в сколько там, встать и пойти домой, отдохнуть. Но я за идею, чтобы пока программист работает, он решал задачи. В общем, нужно дать людям поработать. Я совершенно точно знаю, что разработка - это кайф, и хочу дать другим разработчикам ощутить этот кайф.
При планировании задач я теряю частичку своего времени, и личной продуктивности. Но это окупается скоростью команды. Я жертвую свое время, но в результате общая скорость команды возрастает.
Обращайте внимание на людей. Банально, просто, и очень важно. Дайте каждому ощутить важность своей работы. Я хвалю свою команду, мне искренне интересно кто что делал, что не получается, где можно помочь. Я спрашиваю у людей, как они отдохнули - мне важно, чтобы моя команда была отдохнувшая, и готовая на подвиги. Я хочу, чтобы они развивались как разработчики. Мне интересно созвониться, помочь в чем-то.
Если обращать внимание на человека, интересоваться его успехами - он намного лучше работает. Просто потому что кому-то не все равно, чем он там занимается.
Резюмируя, эффективность - штука, на которую совершенно точно можно влиять. Одна и та же команда может очень по разному работать, и именно руководитель отвечает за ее эффективность.
805 views07:59
П
