Меня зовут Андрей Глушко. Я менеджер ИТ проектов, занимаюсь менторством, прошёл путь от разработчика до руководителя, в своих подходах опираюсь в первую очередь на людей, а потом уже на практики.
Сегодня я хочу поделиться своим подходом в постановке задачи для сотрудника.
На своём опыте я понял, что необходимо найти баланс между вовлечением сотрудника в цели компании и его собственными целями. Поэтому для себя я определил, что важно уметь ставить задачи таким образом, чтобы это затягивало сотрудника в предметную область его позиции и, он осознавал зачем выполняется эта задача в целях бизнеса.
Про цели компании
Для начала я стараюсь выяснить насколько необходимо вовлекать сотрудника в цели проекта или компании. Рассмотрим несколько вариантов:
Если это внештатный сотрудник, с которым я не собираюсь в дальнейшем работать, то постановка задачи в виде инструкций, на мой взгляд, будет самым подходящим вариантом. Нет необходимости создавать дополнительные встречи для обсуждения, чтобы объяснить, как конкретная задача ложится в роадмап фирмы. Я хочу просто получить результат от исполнителя.
Если это внештатный сотрудник на тестовом задании. В таком случае, я уже стараюсь начать вовлекать потенциального сотрудника в дела фирмы, и чтобы он мог принимать самостоятельные решения в случае вопросов, а не постоянно бегать ко мне за уточнениями.
Другая ситуация, если это штатный сотрудник. Здесь для меня уже вопрос стоит не в том вовлекать ли сотрудника или нет. В данном случае я оцениваю сколько ему нужно дать информации о целях фирмы, чтобы он мог комфортно осознавать и брать ответственность за свою задачу.
Про постановку задачи
После того как мне стала ясна необходимость и степень вовлечения, для развития высокой лояльности сотрудников в фирме, я определяю детальность постановки задачи. Согласитесь, можно сказать в виде инструкций “Пётр, нам нужно поставить ‘конкретный сервис кеширования’ применив техники ‘техника_1’ и ‘техника_2’”. По сути, таким образом, я забираю у сотрудника мотивацию и желание проявлять инициативность. Однако, бывает и такое, что сотрудник пока что новичок, и если я ему доверю много ответственности, перенеся на его плечи решения по выбору конкретных технологий и методик исполнения вашей задачи, то высок шанс, что он провалит исполнение задачи. Поэтому я делаю следующее:
Определяю насколько развиты hard skills исполнителя. Если это senior, который много повидал и который разбирается в системе компании, будет проще ему делегировать анализ и выбор конкретных решений. И я ставлю задачу в виде бизнес цели, которую необходимо достичь.
Опираюсь на зоны ответственности между мной и исполнителем. Независимо от того, насколько у сотрудника сильные hard skills, я стараюсь следить за тем, чтобы не перекладывать на него ту часть ответственности, которая лежит на мне. Ведь если я менеджер проекта, то переносить на программиста обязательство выбора бизнес направлений для решения задачи будет демотивирующим для него. Поэтому я придерживаюсь стратегии дать сотруднику выбор, но при этом не перегрузить его этим выбором. Как следствие, я стараюсь показать ему какие есть рамки бизнес требований, которые необходимо соблюсти при выполнении задач уже на техническом уровне.
Про ресурсы проекта
Заключительным, но не менее важное - я выставляю ресурсные ожидания по выполнению задачи. Как это не печально, но все задания и таски могут быть не выполнены в срок, шанс этого всегда присутствует. Здесь представляется принципиальным для меня, опять же, не перекладывать на сотрудника ответственность за потраченные ресурсы компании. Поэтому я если я знаю, что задача срочная, то времени проводить дополнительные митинги для брейншторма просто нет, и я их не провожу. Как итог, выдаю задачу в виде инструкций. С другой стороны, если я понимаю, что на данный момент у команды есть время и что в случае провала задачи проект не будет на грани, то я уже составляю задачу в более вовлеченной форме для сотрудника.
Подводя итог
На основе моих рассуждений, я создал некоторую классификацию видов постановки задачи для сотрудника, в зависимости от уровня его вовлеченности в бизнесовую часть фирмы:
На уровне бизнес проблемы: “Клиентам важно понимать насколько наше приложение надёжное” Сотрудник, как решение этой проблемы, может внедрить monitoring систему, и он сам принимает решения о выборе способа закрытия проблемы.
На уровне бизнес цели: “Мы хотим показать клиентам, что наше приложение надёжное. Это можно сделать через uptime/downtime метрики. {Дальше даются бизнес требования}” Сотрудник уже лучше осознаёт в каком направлении двигаться и как этого можно добиться.
На уровне цели исполнителя: “Мы решили, что мы должны ввести uptime/downtime метрики, чтобы клиент лучше понимал насколько у нас надёжное приложение” За сотрудника решили, что конкретно необходимо сделать, на нём остаётся выбор какими инструментами этого он сможет достичь.
На уровне инструкций для исполнителя: “Нам нужно ввести monitoring system для расчёта метрик uptime/downtime для нашего приложения. Мы будем имплементировать собственное решение, а не использовать сторонние сервисы. Используй nodejs и чтобы логи шли в elasticsearch, а графики строились через библиотеку chartjs” Тут мало остаётся пространства для самого сотрудника, но и этот вариант подходит в некоторых ситуациях.
Эти виды постановки задачи можно представить в виде простого графика: чем больше сотрудник вовлечён в бизнес, тем меньше ему необходимо детализировать задачу
На этом у меня все. Буду рад обратной связи!
Комментарии (21)
RigidStyle
00.00.0000 00:00+5Только это оторвано от реальности. Не, конечно, вы получите аптайм-даунтайм метрики, и успешно освоите деньги инвесторов, но это не то, что вообще требуется клиенту, и не то, что покажет ему, что ваше приложение надежное, потому что никто в это, во первых, не верит, во вторых, не собирается верить. Клиенту важно не то, какие вы себе метрики нарисовали, а что будет, если вы провалите свои обещания.
Ну из разряда: вот вы платите нам абонку 30 баксов в месяц, и по договору, за время даунтайма мы вернем вам деньги. То-есть если месяц будет лежать приложение, то вы вернете 30 долларов. Нормальный клиент скажет "досвидание" если у него будет альтернатива. Но в то же время если вы скажете, что "вот у нас метрики, и даунтайм у нас 1% от общего времени, поэтому если в течении месяца даунтайм будет больше 1%, но меньше 5%, то мы вернем вам всю сумму за месяц, а если больше 5%, то вы получите год бесплатно.
Тогда можно вести диалог. Ну если это приложение корпоративного сегмента, например, где аптайм критически важен, а не какая то считался взмахов телефоном.
А ваши метрики, это просто сферические попугаи в вакууме, которые никому не сдались, потому что всегда можно сказать что "никогда такого не было, это первый раз, что приложение лежит две недели, ну в смысле опять первый раз, а так у нас все ровно по аптайму".
Отсюда никакой из вариантов постановки задачи, описанных в посте, не позволит от сотрудника получить тот вариант предложения для клиента, что я написал выше. Ну со вторым и последующими вариантами все понятно, там просто нужны руки, которые задачу реализуют, но первый вариант так же не дает нужного результата. Отсюда нужно еще научиться ставить задачи так, что бы изначально в них был смысл и практическое применение помимо освоения бюджета инверторов. И вот с этим у менеджеров огромные проблемы. Так как они сами не понимают, что и зачем они делают.
dreikaaa Автор
00.00.0000 00:00-1Вы правы, что некоторые фирмы этим злоупотребляют и включают эти метрики в УТП, когда продают свой сервис клиентами или стейкхоледрам, хотя на деле это просто цифры. Однако, у меня есть оптимистические ожидания того, что такой подход в некоторых фирмах будет постепенно уходить в прошлое.
Если говорить про ответственность, когда эти метрики не удовлетворяются, то как раз плюшки по гарантии и могут быть причиной для клиента выбрать вас. Вспомните обычные ритейл магазины, раньше там не было ни обмена, ни возврата, могли ещё и не оригинал подсунуть. Сейчас уже почти стандарт, что в случае брака или причины "не понравилось", покупатель сможет вернуть товар и не понесет финансовых потерь.
Почему я делаю такое сравнение? Потому что ИТ услуги по сути тоже ритейл(компания закупает рабочую силу дешевле, а продаёт результаты рабочей силы дороже), но намного более сложного товара. И этот товар требует, мне кажется, больше времени, чтобы вокруг него организовались стандарты и регуляции в случае обмана или недобросовестного исполнения со стороны "продавца".
raamid
00.00.0000 00:00+2В целом все правильно, на мой взгляд. Особенно порадовало то, что вы пытаетесь найти баланс между целями сотрудника и целями компании. Поверьте, сотрудники это ценят. Однако, ничего не сказано про сопровождение сотрудника в процессе выполнения работы. В моей практике никогда не бывало такого, чтобы задача уровня сложности выше очень легкой выполнялась без дополнительных вопросов и согласований. И вот здесь тоже возможны варианты. Например:
Поставить задачу и "уйти в закат" до дедлайна
Поставить задачу и быть на связи
Поставить задачу и требовать ежедневной отчетности о ходе выполнения.
Каждый способ имеет свои плюсы и минусы (даже первый). Было бы здорово почитать и про это.
dreikaaa Автор
00.00.0000 00:00-1Спасибо за обратную связь. Я добавил себе в закладки эту тему. Заранее могу сказать, что там тоже много подводных камней :)
iosuslov
00.00.0000 00:00+9TL:DR; Если сотрудник давно работает в конторе и шарит в процессах и технологиях - можно сказать ему "Васян, давай запилим метрики х и у, чтоб менеджер мог на них глядеть". Если сотрудник не шарит в технологиях - "Васян, возьми либу 1, либу 2, почитай про метрики тут, скопируй код отсюда, перемешай, взболтай и сделай, чтобы было красиво". Если Васян совсем новичок в конторе - расписывает ему алгоритм по пунктам.
Основная (единственная?) проблема с таким подходом в ИТ - то, что средний срок работы Васяна в компании 2-3 года. За это время сложно обрасти глубоким пониманием, процессов и окружающих людей.
Поэтому приходится дробить задачи на меньшие куски и отдавать их разным Васянам. Кусок про коммуникацию - тому, кто бухал со всеми на корпоративах. Кусок про выбор решения - тому, кто посмотрел все доки на все либы используемые в конторе. Непосредственную реализацию - тому, кто просто фигачит код и не заморачивается.
По сути - это конвейер, где каждый делает свой кусочек. Но снежинки приходят в ужас о осознания этого факта
dreikaaa Автор
00.00.0000 00:00Это ли не командная работа, когда каждый делает то, что у него получается лучше всего? А там уже и практики создания кросс функциональных команд пригодятся, чтобы процессы не завязывались на одном конкретном человеке
irony_iron
00.00.0000 00:00+2в моей практике важнее обозначить критерии приемки задачи, чем цели и мотивации, если не сказать как будешь проверять, ничего и не будет сделано
dreikaaa Автор
00.00.0000 00:00Согласен, критерии приёмки важны при постановке задачи. Статью можно было бы дополнить этим. При этом, в разных постановках задачи будут разные примеры критериев
spirit1984
00.00.0000 00:00+2Задача нахождения баланса между интересами сотрудника и компании гораздо сложнее и интереснее, чем может показаться на первый взгляд. А происходит это потому, что интересы сотрудника и компании не просто "Не совсем пересекаются", а, скорее всего (не факт, но скорее всего), прямо противоречат друг другу. В чем вообще интересы сотрудника как разработчика? Быть в тренде последних технологий, осваивать постоянно что-то новое и т.д. Однако может ли компания такое предложить? Если это не R&D отдел какой-нибудь крупной корпорации, скорее всего, нет. Смотрите, в стандартном IT-отделе, куда Вы приходите устраиваться, есть проект, которому хотя бы года два. Если менеджмент в отделе толковый, то очевидно, что этот проект два года назад не начинался на cutting-edge фреймворке, у которого на тот момент коммюнити состоит из полутора программистов. Т.е. этот проект начинался на какой-нибудь апробированной технологии, которая уже года два-три хотя бы известна и используется. Получается, что вам в лучше случае удастся поработать на технологиях пятилетней давности. И, естественно, при найме очередного программиста никто не будет резко менять стек проекта, чтоб ему было интересно. Естественно, при заведении нового проекта начинает давить бремя знания - ведь стек старого уже освоен, а с новым стеком еще надо набивать шишки. Поэтому 5 лет устаревания - это еще мягко и весьма неплохо, запросто может оказаться, что программисту надо работать на движке 10-15 летней давности. Это в интересах бизнеса, но не разработчика. И соблюсти здесь баланс руководителю проекта сложно - это одна из самых непростых задач, с которыми он столкнется.
dreikaaa Автор
00.00.0000 00:00Хорошее замечание. Мой пост действительно не рассказывает про эту часть взаимодействия с сотрудником. У меня есть в планах написать статью про тему, как удерживать сотрудника или лучше сказать, как заинтересовать сотрудника задачами фирмы.
Если вкратце, то в своём подходе я пытаюсь достигнуть хорошей рабочей атмосферы через две вещи. Первое, при найме я дополнительно разговариваю с кандидатом о рабочих принципах, давая ему ситуации, после чего спрашиваю как бы он действовал в них. Так, я по крайней мере набираю людей, которые близки мне по "вайбу". Через это мы сможем легче договариваться. А второе - это уже через открытость к дискуссиям, мы стараемся прийти к компромиссам между его желаниями и тем, что я могу дать внутри проекта, во время нашей совместной работы.
Всё равно ведь в течение проекта потребуется проанализировать разные методы выполнения задачи, проанализировать пути разработки(грубо говоря, нужны ли нам конкретно сейчас микросервисы или нет), также будет возможность сделать презентацию для демо и провести презентацию во время демо, и так далее. Так и появится некая "не рутинность" для сотрудника
Ivan22
00.00.0000 00:00+2технологии это еще малая часть проблемы. Гораздо сложнее - когда разработчику нужно для уточнения требований искать нужных стейкхолдеров, вылавливать неделями, потом разговаривать с ними, а их еще и не один и не два, а требования протеворечивые, лексикон непонятный. И всё настолько выводит из себя простого програмиста который любит писать код, что он воскликакает в сердцах. "Боже, а что если придумать какого-то человека который бы вместо меня ходил бы по всем этим людям, и пусть они капают ему на мозги своими противоречиями и хотелками, а он бы из всего этого треша выдввал мне нормальное ТЕХНИЧЕСКОЕ задание." И Господь услышал молитвы и создал бизнес-аналитика, и посмотрел на труды свои и воскликнул "Да будет так!"
korva
00.00.0000 00:00+1Мало пространства... Вы бы видели мои ТЗ. Это лежит там, это тут, вот запрос (я бывший разработчик баз данных и пишу запросы лучше 99% программистов и пока ещё лучше ORM), добавить запрос в такой-то файл, в функцию такую-то, создать такой-то ресурс и так далее. Кажется это и есть отсутствие пространства )
А когда я делал свой стартапчик, то задания для программистов были на уровне сигнатур функций и очень детального разъяснения что делать, где брать, куда ложить и что подавать на выход.
Наверное зря я так...
b00b1ik
от разработчика до руководителя! я был никем и стал важным боссом))))
вы и не менеджер и не аналитик и не архитектор, а так, обычный "манагер".
требованиями и в том числе бизнес, пусть занимаются аналитики, архитекторы пусть занимают на чем и как писать код. а вы поймите что руководитель проектов это другое направление деятельности в отличии от разработки и займитесь своими задачами, хотя бы узнайте зачем вообще РП нужен))
Abysswalker94
Жестко)
agoncharov
Почему откровенное хамство набирает столько плюсов? Вот вам и хабр
dreikaaa Автор
Я рад, если моя статья помогла вам выплеснуть энергию внутри и вам стало от этого лучше/легче
Если отвечать на ваш комментарий, то мне непонятно как вы смогли сделать такой быстрый вывод обо мне, прочитав только одну статью
b00b1ik
а кто сказал что мне стало лучше\легче? это называется - Демагогические приёмы.
я тоже могу так сделать: "вы не рады, вы пытаетесь выпутаться из того что вас .... блаблабла".
видите, я сказал утверждение, сам объявил его истиной и на нем построил дальше предложение. так делать плохо ;)
как я сделал вывод? ну у вас в профиле написано что вы ментор РПшников в ИТ, канал вон свой ведете. пришли со статьей не реальных кейсов, а скорее со "стратегией". А значит хотите задать вектор для юных умов, т.е. джунов.
почему жестко ... потому что вы в первом же предложении в целом, то обидели разработчиков (ни некрасиво это писать от <должность> до <должность> ... вы поставили сразу себя на ранг выше, хотя это разные профессии вообще-то). Ну а во вторых такие статьи портят и без того ОЧЕНЬ скудным мир толковых руководителей, тем что на старте их отправляют туда, куда лучше не ходить и в целом рисуют им корявую парадигму.
ну и потому что видимо неделя такая на хабре "стратегов" писать статьи "флаги", прибежали, помахали, думали плюсами закидают? нет, тут иногда и покритиковать могут. вы как говорил один мой друг просто "не в профессии". но увы таких основная масса в мире РП (( вот такая печалька))
имхо, вы видели статьи про докер стратегические?)
ну так уместите стратегию свою в пару абзацев и просто поделитесь опытом в статье на конкретном примере что и как делали. как вы выбрали архитектуру когда разраб джун был, откуда у вас был опыт пул или пуш модель передачи данных сделать, как вы конкретную бизнес цель замапили на фичу системы и почему сделали фичу, а не просто какое-то изменение процесса например, покажите описание какое фиче сделали (сиквенсы, датафлоу и т.д.), как тестеры ваши требования протестировали, кто ПРы принимал и за архитектурой следил, как оценку делали, какой методикой следили за прогрессом, с какой дискретой, что дало, какие решения были приняты на основе метрик ... обычную работу короче РП то опишите, а не это вот все блаблаба.
ох, махнул я коммент, извините если обидело. но на обижены воду возят. а то нам хватает ванильных разработчиков)
dreikaaa Автор
Прям по пунктам буду отвечать
На самом деле, вы именно тот, кого я и искал, кто поможет мне отточить подачу постов так, чтобы они заходили большему количеству людей :)
-------------------------------------------------------------------------------------------------------------------------
Где вы увидели утверждение в моих словах? Там стоит слово “если”, которое как раз обуславливает моё предположение, иначе мне совсем неясно зачем заниматься критикой без оснований.
-------------------------------------------------------------------------------------------------------------------------
Дальше, я не задавал вопрос, почему жёстко, я задал вопрос, почему вообще критика с вашей стороны. Критики бывают разные, бывают те, кто как раз “блаблабла”, бывают те, кто несмотря на жесткую подачу, дают конструктив. Надеюсь вы из второго числа.
-------------------------------------------------------------------------------------------------------------------------
После этого, вы говорите про “потому что вы в первом же предложении в целом, то обидели разработчиков”. Первое предложение это “Меня зовут Андрей Глушко. Я менеджер ИТ проектов, занимаюсь менторством, прошёл путь от разработчика до руководителя, в своих подходах опираюсь в первую очередь на людей, а потом уже на практики.”. Где в этом предложении я обидел кого-то? Я сказал за себя, что я прошёл этот путь, и, что я когда работаю с командой, то опираюсь на запросы людей внутри команды. Где я поставил себя выше?
Хорошо, возможно вы имели в виду первое предложение “На своём опыте я понял, что необходимо найти баланс между вовлечением сотрудника в цели компании и его собственными целями.”. Смысл этого предложения заключается в том, что разным сотрудникам, важно не только давать четкие инструкции, а всё-таки давать пространство для анализа и манёвра, потому что это помогает их продуктивности, им не кажется их работа рутинно и тд. Опять же я не вижу, где я здесь вас задел.
-------------------------------------------------------------------------------------------------------------------------
Далее по тексту у вас идёт, как вы говорите “блаблабла”, потому что вновь нет аргумента(аргументов). Вы начали абзац с одного, говоря что мои статьи портят представление о хороших РП - {Ну а во вторых такие статьи портят и без того ОЧЕНЬ скудным мир толковых руководителей}. Внутри того же предложения переключились на то, что мои стать дают плохое направление для новичков - {на старте их отправляют туда, куда лучше не ходить и в целом рисуют им корявую парадигму}. Потом решили упомянуть, что по какой-то причине неделя такая на хабре. А закончили совсем другим - {тут иногда и покритиковать могут}. В итоге я не понял ни одной темы, что вы упомянули.
-------------------------------------------------------------------------------------------------------------------------
Теперь к этому {имхо, вы видели статьи про докер стратегические?). Банальный пример(утрированный) стратегической задачи по докеру: “Нам необходимо уменьшить время от фидбека клиента до релиза изменений запрашиваемых в фидбеке, докер нам может позволить быстрее пересоздавать environment, если какие-либо изменения в коде происходят. Товарищ Вася, пожалуйста контейнеризируй наш сервис”.
Вот пример статьи, который был в первой строчке запроса в гугл https://bobcares.com/blog/rapid-web-application-deployment-how-to-use-docker-to-reduce-time-to-market/ . Там описывают, как для клиентов важно, чтобы они быстрее получали изменения.
-------------------------------------------------------------------------------------------------------------------------
Чтобы я всё это написал и расписал мне требуется время. К сожалению я не могу внутри одной статьи описать проблему со всех сторон, учитывая все детали, расписывая каждый возможный кейс, древо моих мыслей и так далее.
-------------------------------------------------------------------------------------------------------------------------
Я не обижаюсь. Я люблю критику, критика это хорошо. Но я люблю конструктивную критику, а не основанную на аргументе, что я не расписал внутри статьи множество вещей, о которых мог бы написать.
-------------------------------------------------------------------------------------------------------------------------
Как итог. Вы сами понимаете, что именно вы хотите от меня? Если да, то, пожалуйста, напишите мне конкретно, что именно и где именно не так внутри моей статьи