Эта статья является продолжением темы «неквалифицированного заказчика», а также попыткой проанализировать причины взаимной неудовлетворенности менеджеров и специалистов в неудачных проектах. Думаю, что моим коллегам знакома ситуация, когда проект провалился и команда пытается понять причины.
Толчком для формулирования концепции «неквалифицированного исполнителя» послужила «Черная книга менеджера» Славы Панкратова, а точнее, кусочек из главы 5 «Люди».
Если человек чего-то не делает, есть 4 причины
Именно в такой последовательности эти причины следует рассматривать. Но вот как понять, какая из них привела к неудаче? Идти сверху вниз и использовать методы наблюдения? Просто поговорить «начистоту»? Но не факт, что в результате получим правильное понимание.
Решение я нашел в методологии теории деятельности, элементы которой описаны, например, в статье Елены Мундриевской (ссылки на авторов приведены в конце публикации). Автор статьи приводит некую аксиому (или предикат) деятельности, при следовании которой результат на выходе будет соответствовать заданию на входе. Мне показалось, что разбор ошибок и неудач с использованием этой методики помогает правильно определить причины поражения.
Этот раздел публикации – исключительно цитата из статьи Елены Мундриевской.
Когда есть деятельность, то:
Посмотрите внимательно на этот предикат. Вы согласны, что это и есть деятельность? Если нет, то дальше можно не читать. Введите свое определение деятельности, и мы проверим, насколько оно лучше. Возможно, Вы окажетесь правы. Но если вы соглашаетесь, что определение деятельности верно, то мы можем двигаться дальше.»
Определение «неквалифицированный» не несет никакого негативного оттенка, и обозначает лишь невозможность конкретным исполнителем выполнить поставленную задачу. Используя логику предиката, далее я попытаюсь разобрать причины «неквалифицированной» деятельности и понять, с точки зрения менеджера (заказчика), что позволит перейти к «деятелю квалифицированному».
Возьмем для разбора гипотетическую ситуацию. У менеджера проекта (=заказчика деятельности) есть команда: аналитик и разработчик. Разработчик постоянно срывает сроки, функциональность фичей не соответствует ТЗ, ошибки в каждом релизе и т.д. Менеджеру требуется понять, в чем же причина. Вот как разбор ситуации может укладываться в рамки предложенной методики:
С этим моментом все просто. Если в команде менеджера есть разработчик, то есть Д.
Нормы деятельности закреплены в культуре компании, регламентирующих документах, а также в негласных договоренностях между членами команды (например, источником норм выступает PMBOOK, свод лучших практик, SLA, внутренние договоренности о распределении зон ответственности и т.д.). Чтобы понять, реализуется ли этот пункт, менеджер должен определить исчерпывающий перечень этих норм.
Если нормы не определены, (хотя бы частично) то гарантированно наш разработчик – деятель о них не узнает, и он рискует оказаться «неквалифицированным» «по непониманию».
Следовательно, поддержание актуального и полного нормативного перечня — это обязательная функция менеджера для обеспечения квалификации исполнителя.
Как только нормы начинают определяться, очень важно обеспечить правильное одинаковое понимание этих норм членами команды. Эта активность – вторая важная функция менеджера. Неотъемлемой частью этой функции является обратная связь, позволяющая понять, что исполнитель «понял» транслируемую ему норму — ценность, более того, «понял правильно».
Если нормы не переданы исполнителю и (или) не поняты/поняты неправильно, наш деятель – разработчик оказывается «неквалифицированным» по той же причине – не понимает, что от него ждут.
Следовательно, обеспечение правильного понимания норм деятелем (ценностей, целей, и т.д.) – это вторая обязательная функция менеджера на пути получения «квалифицированного» исполнителя.
Вот этот пункт мне кажется одним из самых интересных. Принимать — это разделять ценности и цели, иметь согласие по принципиальным моментам. Принятие не исключает продуктивных дискуссий, но отсекает пустые и порожние споры. Идеальным результатом реализации этого пункта является команда единомышленников; Согласен что в реальных условиях менеджеру приходится работать с той командой, что удалось собрать, но для того чтобы наш разработчик выполнял свою работу квалифицированно, он должен поддерживать, как минимум, базовые ценности команды.
Если деятель не принимает норму – однозначно он не хочет участвовать в этой деятельности. Насколько бы он не был хорош по всем остальным пунктам, менеджеру следует задуматься о необходимости иметь такую «оппозицию» в проекте.
Здесь все просто. Вопрос связан исключительно с компетенцией исполнителя. Обращаю внимание читателя, что только один фактор из 9, связанных с успешной деятельностью, определяется компетенцией исполнителя. Это как раз тот случай, про который Слава Панкратов говорит – «не умеет». В этом случае менеджер (заказчик) как правило знает, что делать – развивать компетенцию или менять исполнителя.
Однако важно понимать относительный уровень квалификации исполнителя. Т.е. сначала определяется норма, потом – способность исполнителя ее выполнить. Требования к квалификации – первичны. Следовательно, если мы начинаем оценивать специалистов (HR решает ввести практику аттестаций, или планов развития для разработчиков) первично определение шкалы и критериев оценки.
Норма на продукт – это формулировка значимых для заказчика характеристик желаемого результата. Включает в себя: требования к функциональности, стоимостные характеристики, соответствие определенной технологии, возможности масштабирования и много того, что должно сочетаться в идеальном результате. Фактически это критерии приемки.
Неопределенность критериев приемки – одна из главных причин неудачной сдачи продуктов или проектов заказчику; квалифицированный исполнитель, понимающий это не должен браться за такую работу.
Следовательно, если менеджером не определены нормы на продукт, то исполнитель не понимает, что от него требуется, вследствие этого становится «неквалифицированным», т.е. неспособным выполнить работу правильно.
По сути это требования к смежникам на продукт (полуфабрикат) предшествующего передела. Например, для разработчика такой нормой может являться требование к содержанию ТЗ, или тестовый пример, в котором визуализируется требование к разработке и т.д.
Вряд ли формирование этих требований зависит от самого разработчика, я думаю, что требования к меж-функциональному взаимодействию формулируются прежде всего менеджером. Вооруженный такими нормами разработчик понимает, что ТЗ, поступившее к нему от аналитика, содержит достаточно информации и не требует уточнений.
Следовательно, менеджеру следует озадачиваться качественным наполнением информационных потоков в команде. В рамках этой парадигмы недостаточно чтобы «таск» формально появился в «трекере», важно, чтобы этот «таск» содержал в себе ровно столько информации, сколько требуется исполнителю для работы.
Если это правило не соблюдается, мы получаем «неквалифицированного исполнителя» опять же по «непониманию» — к этой категории следует относить все проблемы типа «мы считали, что, создавая frontend, специалист сам договорится со специалистом backend, из какой базы брать данные». На мой взгляд, это все-таки задача менеджера – определять требования к входу в процесс.
Еще одна норма, только определяющая, как построен процесс работы. Плохая практика, когда самому исполнителю приходится сначала придумывать для себя процесс, а потом действовать по нему. Представьте, что каждая команда самостоятельно определяет для себя методологию ведения проекта, продолжительность спринтов, условия завершения задач и т.д. Роль менажера в такой ситуации сводится к позиции наблюдателя (даже если он и прикрывается словами о «самоорганизации» в команде) и проект неуправляемо начинает куда-то катиться. Исполнитель оказывается в ситуации непонимания как именно он должен работать, и опять же – получает ярлык «неквалифицированного».
Здесь как мне кажется тоже все просто. Менеджер и команда должы решить, какой стек технологий будет использоваться, какая архитектура является оптимальной и т.д.
Читатель безусловно обратил внимание: среди десятка причин, по которым исполнитель признается «неквалифицированным», только одна связана непосредственно с уровнем подготовки исполнителя, ситуация, когда он не может выполнить поручение. В остальных случаях уровень квалификации определяется прежде всего способностью менеджера или заказчика правильно сформулировать требования к продукту. Т.е. квалификация менеджера/заказчика при производстве продукта – первична.
В любой ситуации, где нормы на деятельность не определены, даже самый опытный исполнитель всегда рискует «не угадать» и выдать «не совсем то, что хотели получить». В действительности же признавать исполнителя «неквалифицированным» мы можем только в случаях, когда он либо не принимает нормы, либо не способен их выполнить. Во всех остальных ситуациях следует признавать — исполнитель «не понял», и искать пробелы в менеджменте. Менеджер (заказчик) является носителем норм. Неспособность сформулировать и донести эти нормы приводит к тому что в процессе деятельности появляется т.н. «неквалифицированный заказчик».
В моем представлении, неквалифицированный исполнитель в большинстве случаев появляется только в паре с неквалифицированным заказчиком.
Исключение составляют случаи, когда исполнитель не принимает ценности компании («не хочет» по определению Панкратова) или просто не обладает достаточным уровнем знаний или умений («не умеет»).
Все остальные причины неудач следует искать на уровне заказчика (или менеджера), а точнее, начинать искать с этой точки.
Безусловно, менеджмент – наука неточная, скорее даже вид искусства, но, использование элементов теории деятельности, на мой взгляд, позволяет упорядочить процесс поиска и идентификации ошибок, если у команды есть желание докопаться до истины.
Должен так же отметить, что будет плохой практикой со стороны исполнителя прийти с этой статьей к менеджеру и потребовать для начала установить и прописать все нормы. В реальной жизни эти нормы есть всегда, чаще в неписанном виде, достаточно часто они формируются стихийно и ситуативно по мере развития команды. Следование предикату позволяет идентифицировать эти нормы, разложить их по полочкам и понять, в каких местах требуется улучшение.
Для думающего менеджера важнее понимать, какими нормами в данный момент руководствуется команда, и корректировать эти нормы методами управления чем попытка задокументировать все что можно и визуализировать все при помощи Visio; сами нормы подвержены быстрой трансформации, документирование всегда будет описывать «вчерашний» процесс.
Я так же не призываю совсем отказываться от документирования – т.к. записи нужны для того чтобы не забыть важные договоренности. Действительно важные нормы должны фиксироваться по мере того, как команда достигает консенсуса по ним. Например: критерии приемки-сдачи продукта; интерфейсы модулей в продукте; условия трудовых контрактов в команде и т.д.
Копание теории деятельности, в частности, нормирования продукта, привело меня к формированию методологии управления продуктом, которую, если будет возможность, буду развивать в следующих публикациях. А также к вопросам мотивации менеджера – поиску такой системы стимулирования деятельности, которая побуждает руководителя организовывать производственную кооперацию максимально эффективно.
Толчком для формулирования концепции «неквалифицированного исполнителя» послужила «Черная книга менеджера» Славы Панкратова, а точнее, кусочек из главы 5 «Люди».
Если человек чего-то не делает, есть 4 причины
- Не понял
- Не умеет
- Не может
- Не хочет»
Именно в такой последовательности эти причины следует рассматривать. Но вот как понять, какая из них привела к неудаче? Идти сверху вниз и использовать методы наблюдения? Просто поговорить «начистоту»? Но не факт, что в результате получим правильное понимание.
Решение я нашел в методологии теории деятельности, элементы которой описаны, например, в статье Елены Мундриевской (ссылки на авторов приведены в конце публикации). Автор статьи приводит некую аксиому (или предикат) деятельности, при следовании которой результат на выходе будет соответствовать заданию на входе. Мне показалось, что разбор ошибок и неудач с использованием этой методики помогает правильно определить причины поражения.
Немного теории (предикат деятельности)
Этот раздел публикации – исключительно цитата из статьи Елены Мундриевской.
Когда есть деятельность, то:
- Должен быть деятель (Д).
- У Д должна быть норма деятельности.
- Д должен понимать норму.
- Д должен принимать норму.
- Д должен быть способен выполнять эту норму.
- Должна быть норма на продукт деятельности
- Должна быть норма на исходный материал для получения продукта деятельности.
- Должна быть норма на процесс преобразования исходного материала в продукт.
- Должна быть норма на средства преобразования исходного материала в продукт, применяемые в процессе преобразования.
- Должна быть норма на способ применения средства преобразования.
- Должна иметь место реализация всех норм.
- Деятельность имеет место тогда и только тогда, когда есть все вышеуказанное.
Посмотрите внимательно на этот предикат. Вы согласны, что это и есть деятельность? Если нет, то дальше можно не читать. Введите свое определение деятельности, и мы проверим, насколько оно лучше. Возможно, Вы окажетесь правы. Но если вы соглашаетесь, что определение деятельности верно, то мы можем двигаться дальше.»
Квалифицированный и неквалифицированный исполнитель
Определение «неквалифицированный» не несет никакого негативного оттенка, и обозначает лишь невозможность конкретным исполнителем выполнить поставленную задачу. Используя логику предиката, далее я попытаюсь разобрать причины «неквалифицированной» деятельности и понять, с точки зрения менеджера (заказчика), что позволит перейти к «деятелю квалифицированному».
Возьмем для разбора гипотетическую ситуацию. У менеджера проекта (=заказчика деятельности) есть команда: аналитик и разработчик. Разработчик постоянно срывает сроки, функциональность фичей не соответствует ТЗ, ошибки в каждом релизе и т.д. Менеджеру требуется понять, в чем же причина. Вот как разбор ситуации может укладываться в рамки предложенной методики:
1. Должен быть деятель
С этим моментом все просто. Если в команде менеджера есть разработчик, то есть Д.
2. У Деятеля должна быть норма деятельности
Нормы деятельности закреплены в культуре компании, регламентирующих документах, а также в негласных договоренностях между членами команды (например, источником норм выступает PMBOOK, свод лучших практик, SLA, внутренние договоренности о распределении зон ответственности и т.д.). Чтобы понять, реализуется ли этот пункт, менеджер должен определить исчерпывающий перечень этих норм.
Если нормы не определены, (хотя бы частично) то гарантированно наш разработчик – деятель о них не узнает, и он рискует оказаться «неквалифицированным» «по непониманию».
Следовательно, поддержание актуального и полного нормативного перечня — это обязательная функция менеджера для обеспечения квалификации исполнителя.
3. Деятель должен понимать норму
Как только нормы начинают определяться, очень важно обеспечить правильное одинаковое понимание этих норм членами команды. Эта активность – вторая важная функция менеджера. Неотъемлемой частью этой функции является обратная связь, позволяющая понять, что исполнитель «понял» транслируемую ему норму — ценность, более того, «понял правильно».
Если нормы не переданы исполнителю и (или) не поняты/поняты неправильно, наш деятель – разработчик оказывается «неквалифицированным» по той же причине – не понимает, что от него ждут.
Следовательно, обеспечение правильного понимания норм деятелем (ценностей, целей, и т.д.) – это вторая обязательная функция менеджера на пути получения «квалифицированного» исполнителя.
4. Деятель должен принимать норму
Вот этот пункт мне кажется одним из самых интересных. Принимать — это разделять ценности и цели, иметь согласие по принципиальным моментам. Принятие не исключает продуктивных дискуссий, но отсекает пустые и порожние споры. Идеальным результатом реализации этого пункта является команда единомышленников; Согласен что в реальных условиях менеджеру приходится работать с той командой, что удалось собрать, но для того чтобы наш разработчик выполнял свою работу квалифицированно, он должен поддерживать, как минимум, базовые ценности команды.
Если деятель не принимает норму – однозначно он не хочет участвовать в этой деятельности. Насколько бы он не был хорош по всем остальным пунктам, менеджеру следует задуматься о необходимости иметь такую «оппозицию» в проекте.
5. Деятель должен быть способен выполнять эту норму
Здесь все просто. Вопрос связан исключительно с компетенцией исполнителя. Обращаю внимание читателя, что только один фактор из 9, связанных с успешной деятельностью, определяется компетенцией исполнителя. Это как раз тот случай, про который Слава Панкратов говорит – «не умеет». В этом случае менеджер (заказчик) как правило знает, что делать – развивать компетенцию или менять исполнителя.
Однако важно понимать относительный уровень квалификации исполнителя. Т.е. сначала определяется норма, потом – способность исполнителя ее выполнить. Требования к квалификации – первичны. Следовательно, если мы начинаем оценивать специалистов (HR решает ввести практику аттестаций, или планов развития для разработчиков) первично определение шкалы и критериев оценки.
6. Должна быть норма на продукт деятельности
Норма на продукт – это формулировка значимых для заказчика характеристик желаемого результата. Включает в себя: требования к функциональности, стоимостные характеристики, соответствие определенной технологии, возможности масштабирования и много того, что должно сочетаться в идеальном результате. Фактически это критерии приемки.
Неопределенность критериев приемки – одна из главных причин неудачной сдачи продуктов или проектов заказчику; квалифицированный исполнитель, понимающий это не должен браться за такую работу.
Следовательно, если менеджером не определены нормы на продукт, то исполнитель не понимает, что от него требуется, вследствие этого становится «неквалифицированным», т.е. неспособным выполнить работу правильно.
7. Должна быть норма на исходный материал для получения продукта деятельности
По сути это требования к смежникам на продукт (полуфабрикат) предшествующего передела. Например, для разработчика такой нормой может являться требование к содержанию ТЗ, или тестовый пример, в котором визуализируется требование к разработке и т.д.
Вряд ли формирование этих требований зависит от самого разработчика, я думаю, что требования к меж-функциональному взаимодействию формулируются прежде всего менеджером. Вооруженный такими нормами разработчик понимает, что ТЗ, поступившее к нему от аналитика, содержит достаточно информации и не требует уточнений.
Следовательно, менеджеру следует озадачиваться качественным наполнением информационных потоков в команде. В рамках этой парадигмы недостаточно чтобы «таск» формально появился в «трекере», важно, чтобы этот «таск» содержал в себе ровно столько информации, сколько требуется исполнителю для работы.
Если это правило не соблюдается, мы получаем «неквалифицированного исполнителя» опять же по «непониманию» — к этой категории следует относить все проблемы типа «мы считали, что, создавая frontend, специалист сам договорится со специалистом backend, из какой базы брать данные». На мой взгляд, это все-таки задача менеджера – определять требования к входу в процесс.
8. Должна быть норма на процесс преобразования исходного материала в продукт
Еще одна норма, только определяющая, как построен процесс работы. Плохая практика, когда самому исполнителю приходится сначала придумывать для себя процесс, а потом действовать по нему. Представьте, что каждая команда самостоятельно определяет для себя методологию ведения проекта, продолжительность спринтов, условия завершения задач и т.д. Роль менажера в такой ситуации сводится к позиции наблюдателя (даже если он и прикрывается словами о «самоорганизации» в команде) и проект неуправляемо начинает куда-то катиться. Исполнитель оказывается в ситуации непонимания как именно он должен работать, и опять же – получает ярлык «неквалифицированного».
9. и 10. Должна быть норма на средства преобразования исходного материала в продукт, применяемые в процессе преобразования, и на способ преобразования
Здесь как мне кажется тоже все просто. Менеджер и команда должы решить, какой стек технологий будет использоваться, какая архитектура является оптимальной и т.д.
11. и 12. Должна иметь место реализация всех норм. Деятельность имеет место тогда и только тогда, когда есть все вышеуказанное
Читатель безусловно обратил внимание: среди десятка причин, по которым исполнитель признается «неквалифицированным», только одна связана непосредственно с уровнем подготовки исполнителя, ситуация, когда он не может выполнить поручение. В остальных случаях уровень квалификации определяется прежде всего способностью менеджера или заказчика правильно сформулировать требования к продукту. Т.е. квалификация менеджера/заказчика при производстве продукта – первична.
В любой ситуации, где нормы на деятельность не определены, даже самый опытный исполнитель всегда рискует «не угадать» и выдать «не совсем то, что хотели получить». В действительности же признавать исполнителя «неквалифицированным» мы можем только в случаях, когда он либо не принимает нормы, либо не способен их выполнить. Во всех остальных ситуациях следует признавать — исполнитель «не понял», и искать пробелы в менеджменте. Менеджер (заказчик) является носителем норм. Неспособность сформулировать и донести эти нормы приводит к тому что в процессе деятельности появляется т.н. «неквалифицированный заказчик».
Выводы:
В моем представлении, неквалифицированный исполнитель в большинстве случаев появляется только в паре с неквалифицированным заказчиком.
Исключение составляют случаи, когда исполнитель не принимает ценности компании («не хочет» по определению Панкратова) или просто не обладает достаточным уровнем знаний или умений («не умеет»).
Все остальные причины неудач следует искать на уровне заказчика (или менеджера), а точнее, начинать искать с этой точки.
Безусловно, менеджмент – наука неточная, скорее даже вид искусства, но, использование элементов теории деятельности, на мой взгляд, позволяет упорядочить процесс поиска и идентификации ошибок, если у команды есть желание докопаться до истины.
Должен так же отметить, что будет плохой практикой со стороны исполнителя прийти с этой статьей к менеджеру и потребовать для начала установить и прописать все нормы. В реальной жизни эти нормы есть всегда, чаще в неписанном виде, достаточно часто они формируются стихийно и ситуативно по мере развития команды. Следование предикату позволяет идентифицировать эти нормы, разложить их по полочкам и понять, в каких местах требуется улучшение.
Для думающего менеджера важнее понимать, какими нормами в данный момент руководствуется команда, и корректировать эти нормы методами управления чем попытка задокументировать все что можно и визуализировать все при помощи Visio; сами нормы подвержены быстрой трансформации, документирование всегда будет описывать «вчерашний» процесс.
Я так же не призываю совсем отказываться от документирования – т.к. записи нужны для того чтобы не забыть важные договоренности. Действительно важные нормы должны фиксироваться по мере того, как команда достигает консенсуса по ним. Например: критерии приемки-сдачи продукта; интерфейсы модулей в продукте; условия трудовых контрактов в команде и т.д.
Заключение
Копание теории деятельности, в частности, нормирования продукта, привело меня к формированию методологии управления продуктом, которую, если будет возможность, буду развивать в следующих публикациях. А также к вопросам мотивации менеджера – поиску такой системы стимулирования деятельности, которая побуждает руководителя организовывать производственную кооперацию максимально эффективно.
Ссылки
- Слава Панкратов «Черная книга менеджера» — доступна для скачивания.
- Елена Мундриевская «Тест на cтратега» «Экономические стратегии», №08-2006, стр. 172-175, статью так же можно прочитать по ссылке.
