Единственное не особо радует у нас в стране: основная часть менеджеров все-таки работает исходя из сложившейся ситуации, а не продумывая  свою (и не только свою) деятельность заранее. И, к сожалению, это относится к менеджерам разного уровня (от обычного руководителя проектов до некоторых руководителе организаций). Но при наличии таких качественных материалов, которые можно найти на happy-pm.com, ситуация должна постепенно выправляться – главное, чтобы всегда были те, кто хочет учиться.

Похожие статьи:

1. Разбор кейсов «О чем говорят менеджеры»

В связи с этим написал разбор кейсов не по конкретным ситуациям, а с описанием из разряда «как не наступить на грабли». Вот что получилось:

1. Про непрерывность бизнеса и сгоревший дата-центр

В бизнесе менеджеры часто не работают с рисками. И тем более не помнят прописной истины: не клади все яйца в одну корзину (народная пословица). Это значит, что не стоит концентрироваться на одном направлении – работайте в нескольких. Если одно из направлений «сдохнет», то удар будет не такой серьезный при наличии других источников дохода. Здесь риски не учли владельцы ЦОДа (обычно где-то относительно далеко строится резервный ЦОД и осуществляется их распараллеливание для обеспечения отказоустойчивости), владельцы бизнес-системы (зачастую не стоит полагаться на одного поставщика вычислительных мощностей) и потребители сервисов бизнес-системы (всегда готовь план действий на случай форс-мажора – бэкапы данных никто не отменял в случае отказа системы или перехода к другому поставщику услуг).

2. Эксперимент с региональным офисом

Руководитель регионального офиса – достаточно неопытный менеджер. Открытие нового офиса – это проект. У проекта должны быть результаты. Заказчик всегда должен иметь понимание, по каким критериям он будет оценивать эффективность проекта. Вот и получилось, что менеджер не выполнил своих обязанностей, когда не спросил при найме, что хочет в результате получить заказчик и по каким критериям он будет оценивать результаты проекта.

3. Open source для менеджера и команды

Проекты типа Open Source в основном для коммерческих организаций предназначены для проработки новых технологических или бизнес-решений, а так же для работы над положительным имиджем компании. Зачастую компании на базе Open Source проектов строят расширения, которые превращают в коммерческие продукты (продажи дополнительных сервисов, показ рекламы и т.п.). Вполне понятно, что финансирование этих проектов идет из общей прибыли компании от коммерческой деятельности. Если прибыль снижается, то первыми под нож попадают проекты с туманной перспективой коммерческой отдачи, а потом проекты, потенциально важные, но убыточные или не приносящие прибыли.Что касается работы в проектах Open Source, то любой человек, идя в такой проект, должен понимать, что его рабочее место менее стабильно, чем в коммерческом проекте. При этом ему необходимо понимать, какие перспективы есть у проекта в долгосрочной перспективе. Только после этого можно определить для себя, стоит ли идти.

4. Ловкие в общении ПМ-ы

С архитектором произошла распространенная ошибка, которая стала началом крутого пике. Менеджер не обеспечил обратной связи с участниками проекта. Еще при выполнении работ сотрудниками необходимо регулярно работать со всеми членами проектной команды, понимая их уровень внутренней мотивации, работая с проблемами на ранних этапах их возникновения. Почему нельзя было регулярно встречаться в курилке или на ежедневных встречах и в относительно неформальной обстановке интересоваться о различных трудностях? Ведь намного проще решить проблему в самом начале ее проявления, чем ждать нарыва и острого разрешения проблемы. Поговорив с архитектором заранее, менеджер понял бы, что предстоит сдвиг окончания работ. При этом он мог бы организовать мозговой штурм из ключевых сотрудников в помощь архитектору (не стоит забывать и про предварительную «обработку» архитектора, чтобы не обиделся – «лучше собраться всей командой, может кто и предложит что-то интересное, за что можно будет зацепиться и сдвинуться с мертвой точки»). Ну а если менеджер уже успел наступить на грабли, то в любом случае не стоит давить на человека, пусть даже и по неосторожности – будет только хуже. Если человек обиделся, то стоит как можно раньше «разгребать Авгиевы конюшни», предлагаю совершенно разные варианты, не ограничиваясь на одном. Если уж не удалось вернуть человека в команду, то хотя бы обговорите с ним период времени, в течение которого он смог бы передать свои компетенции другим сотрудникам. При достаточно большом периоде и интенсивной работе с коллективом есть возможность исправить отношения и полноценно вернуть человека в коллектив, сохранив хорошие отношения в команде.С 40 летним программистом та же самая проблема – нет обратной связи. Если ситуация изменилась, то менеджер обязан удостовериться, что все члены команды получили изменения, понимают их и дают свой фидбэк по ним. Возможны такие ситуации, когда какой-то член команды может сказать, что изменение описано не достаточно и требуется дополнительная проработка в таком-то направлении. Так же тут отражена ситуация, когда менеджер совершенно не работает с командой в плане развития – практически все оперируют работниками, как статичными единицами, а люди всегда хотят развиваться. Тут надо просто спрашивать, что интересно тому или иному сотруднику и давать в проекте новые некритичные задачи для развития. Естественно, что без работы с линейным руководителем так же не обойдешься – он тоже должен участвовать в развитии своих сотрудников.

5. Невидимость отечественных менеджеров

Здесь ситуация подобная «ловким менеджерам», но в обратном направлении. Если в региональное подразделение прислали «разнорядку» на увольнение менеджеров, то плохо было поставлено информирование наверх о результатах деятельности. Впрочем это стандартная ситуация, когда отчетность может не учитывать оценку качества работы, а только финансовую часть. Если уж поступило такое «предложение» от руководства, то следует реально оценить ситуацию и понять, кто и какую отдачу дает, какие перспективы есть у каждого. После этого необходимо оценить, что произойдет с проектами при исключении каждого из менеджеров – может быть ситуация, когда в финансовом плане лучше оставить менеджера, чем тратить деньги на исправление ситуации в проектах. Ну а дальше следует трезво подойти ко всем оценкам и понять, требуются ли вообще сокращения, может можно оптимизировать процессы и сократить затраты на этом. Ну а дальше выходить к руководству с конкретными предложениями и реалистичной оценкой ситуации.

Похожие статьи:

1. Разбор кейсов «О чем говорят менеджеры». Комментарии
2. Какие будут современные менеджеры?

Зачастую, задачи для подчиненных ставятся «сверху» – руководство просто ставит исполнителя перед фактом – есть задача, есть сроки, должен  быть такой результат и т.п. Иногда бывает и такое, когда руководство ставит «размытые» задачи – нечетко сформулированные («ну, ты сам потом разберешься…»). В результате, исполнитель не всегда справляется с поставленными задачами.

Что же делать, чтобы более эффективно управлять и выполнять задания? Это должна быть работа двух сторон – того, кто ставит задачу, и того, кто ее исполняет.

Руководитель при постановке задачи обязательно должен согласовать ее содержание и сроки с исполнителем. При этом должно быть получено не формальное, а реальное подтверждение от исполнителя того, что задача полностью понятна и поставленные сроки соответствуют оценочным со стороны исполнителя. Исполнитель же должен при необходимости скорректировать постановку задач и сроки исполнения. Так же могут быть озвучены риски, которые могут возникнуть в процессе выполнения задачи. Если риски могут существенно скорректировать сроки, то необходимо дать две оценки по срокам: пессимистичная (с учетом всех рисков) и ожидаемая (если все пойдет по графику).

Часто бывает, что при реализации достаточно сложной задачи возникают непредвиденные ситуации (срабатывают неизвестные на момент старта работ риски). Иногда, в процессе реализации задачи приходит понимание, что задача оказалась намного сложнее, чем казалось при первоначальной оценке.  В этом случае исполнителю необходимо докладывать руководителю о том, что произошло и как это повлияло на сроки. В сложных ситуациях так же следует подготовить для руководства различные варианты исправления ситуации и их влияние на сроки реализации задачи.

Теперь, если вернуться к нашему правительству и руководству страны, хочется спросить у них: А как работает наше правительство и президент? Не похоже на подобный вариант работы, если слишком часто возникают вопросы о должностном соответствии того или иного чиновника. Им бы учиться у коммерческих организаций управлению задачами и ресурсами.

Похожие статьи:

1. Кто виноват?
2. Пример построения варианта использования (use case) системы. Часть 1
3. Проектирование бизнес-приложения: Процесс разработки ПО

Конструктивный метод, на мой взгляд, заключается в следующем:

1. Необходимо проанализировать сложившуюся ситуацию и понять причины возникновения проблемы. Проблемы могут быть вызваны внешними причинами (поставщик задержал поставку оборудования, случился форс-мажор и т.п.) и внутренними (руководитель на одном из уровней управления не выполнил своевременно необходимые действия, работник неправильно оценил плановые сроки реализации и поэтому сдвинулись конечные сроки и т.п.).
2. Определить план устранения проблемы на основе выявленных причин и реализовать его в жизнь. Следует учесть, что в план устранения может войти как устранение проблемы (замена сотрудника, подрядчика или поставщика, изменение задачи или даже отказ от реализации), так и отсутствие реагирования на проблему, если стоимость устранения проблемы окажется выше, чем ее неустранение, невозможно устранить проблему в приемлемые сроки или срок устранения сопоставим с имеющимися плановыми сроками.
3. Сделать выводы на будущее и спланировать предотвращение подобных ситуаций в будущем.

Одним словом, необходимо качественно применять проектное управление и заранее применять Риск-менеджмент. К сожалению, в России с управлением проектами по устоявшимся методологиям (например, PMBoK) дела обстоят очень плохо – очень немногие организации готовы внедрять и использовать такие методологии.

Похожие статьи:

1. Кто виноват? Часть 2

Возьмем для примера интернет-магазин по продаже книг для небольшого издательства.

От заказчика (коммерческого директора Василия) поступило следующее письмо:

Уважаемые разработчики, наш отдел маркетинга предложил создать собственный интернет-магазин по продаже книг – это позволит повысить прибыль. Прошу разработать и согласовать со мной техническое задание на интернет-магазин.

Данное письмо подразумевает выполнение первого этапа работ – анализ потребностей заказчика и формирование технического задания (ТЗ). Любая работа требует организации и контроля. Для этого руководитель подразделения, где обитают разработчики, аналитики и другие спецы, назначает руководителя проекта. Руководитель проекта формирует команду проекта.

В команду проекта должны войти следующие роли:

• руководитель проекта – отвечает за организацию работ, координирование и контроль действий каждого члена команды;
• аналитик – отвечает за сбор информации, ее обработку и выдачу технического задания на систему;
• архитектор – составляет общее видение архитектуры системы и определяет возможность реализации того или иного сценария работы системы.

Рассмотрим работу самой главной роли на этапе анализа – работу аналитика.

Первоначально аналитик должен определить заказчика проекта (в нашем случае это коммерческий директор Василий). Далее определяется рабочая группа со стороны заказчика, в которую должны входить ключевые заинтересованные лица: сам коммерческий директор Василий, начальник отдела розничных продаж Светлана, начальник отдела доставки Максим, начальник склада Роман.

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

Интервью могут быть очными (рабочая группа собирается в одном помещении) или в электронном виде (например, электронными письмами). Первоначальная встреча обязательно должна быть очной – на ней закладывается основная концепция системы. В ходе интервью должны быть разработаны бизнес-процессы работы системы, собраны требования к ней. Не стоит сразу заниматься очень подробным описанием – на первых интервью необходимо собрать только основную высокоуровневую информацию. После каждого интервью необходимо согласовать с рабочей группой полученную и обработанную информацию – создать документ, описывающий бизнес-процессы и требования.

В результате наших первых встреч с рабочей группой был получен документ по следующему шаблону: Шаблон документа-концепции

После согласования первой версии документа необходимо по полученным высокоуровневым параметрам системы подобрать бесплатные или коммерческие аналоги системы. Если аналог найден, то задача в некоторой степени упрощается – далее будет производиться внедрение системы и ее настройка под требования заказчика. Если удовлетворяющего аналога нет или стоимость и/или трудоемкость внедрения превысит стоимость и трудоемкость разработки своими силами, то принимается решение о разработке новой системы или отказ от системы вообще.

Похожие статьи:

1. Кто виноват? Часть 2

В первой рубрике я буду публиковать то, что меня волнует, но не связано с работой. Во второй же буду писать исключительно о делах околопрограммистских – от разработки до управления разработкой. Так же в дальнейшем я могу дополнить список рубрик интересующими меня темами.

Первоначально необходимо определить последовательность реализации требований. Первыми пойдут требования для построения разработанной архитектуры – будем строить скелет системы. Далее должны идти требования от наиболее важных к наименее важным. Для каждого требования должны быть созданы задачи на реализацию, а для каждой задачи должна быть проставлена оценочная трудоемкость реализации.

При планировании реализации не следует убеждать себя в том, что мы реализуем все требования в первой версии системы. Часто бывает, что появляются неучтенные факторы, которые отодвигают выпуск системы. К тому же часто заказчик системы на этапе сбора требований не всегда четко представляет конечный результат, а проверка реализации дает коррективы в требования. Так же возникают ситуации, когда требования меняются, например, из-за изменений в законах.

Чтобы упростить процесс разработки следует разбить весь проект на итерации. При этом каждая итерация должна продолжаться от одной до четырех недель (в зависимости от сложности подлежащих реализации требований). По итогам каждой итерации должно выполняться тестирование, а для ключевых выпусков (beta, release candidate) осуществляться демонстрация заказчику в целях получения отзывов о системе.

Теперь вернемся к программированию. Каждый программист получает задачу и приступает к ее реализации. Первоначально программист должен еще раз проверить оценочную трудоемкость и при необходимости откорректировать ее. Далее он должен реализовывать задачу в максимально короткие сроки с наивысшим качеством.

Что значит «реализовывать задачу в максимально короткие сроки с наивысшим качеством»?  А значит это следующее:

1. Программист должен сосредоточиться на одной задаче и целиком посвятить себя ей до завершения работ. Редкие люди могут делать одновременно два дела, а частое переключение не позволяет работать эффективно.
2. Программист не должен самостоятельно додумывать нечетко описанные требования или задачи – для этого есть аналитики и архитекторы, в обязанность которых входит получение однозначных, непротиворечивых и полных требований к системе.
3. Если поставленная задача не является типовой, то ее следует обсудить в команде разработки (например, за чашкой чая) – часто кто-нибудь уже реализовывал подобную задачу в своей практике или знает уже частично или полностью реализованное решение (часто бывает проще купить какой-то компонент, чем изобретать велосипед и платить за это лишние деньги).
4. Когда выбран вариант реализации, то его следует обсудить с архитектором и коллегами по команде, т.к. иногда решение может не вписываться в архитектуру или негативно влиять на соседние компоненты системы, разрабатываемые коллегами.
5. Реализация задачи должна обязательно сопровождаться тестирование. Наиболее эффективном способом является автоматизированное юнит-тестирование (unit tests) и проверка покрытия кода (code coverage). Но и о ручной проверке так же не следует забывать, т.к. не всегда программист может учесть в юнит-тесте всю необходимую проверку.

Итак, задача реализована. Что дальше? Дальше наиболее оптимальным вариантом является проверка написанного кода тим-лидером или другим программистом (желательно, более опытным для проверки эффективности реализации, а менее опытному для повышения уровня). По результатам проверки задача может быть отправлена на доработку по замечаниям.

После реализации задачи она должна передаваться на документирование и функциональное тестирование.

Документирование подразумевает создание как минимум двух документов:

1. инструкции пользователя – полное руководство по использованию системы с точки зрения пользователя.
2. инструкции администратора – полное руководство по установке, настройке и поддержанию системы в работоспособном состоянии.

Функциональное тестирование состоит из:

1. Создания тестов для проверки требований. Обычно создаются комплексные тесты, проверяющие несколько требований.
2. Проверки инструкций на достаточность, легкую воспринимаемость и соответствие требованиям и тестам.
3. Проведение тестов по установке, настройке и использованию системы.

По результатам проводимых тестов задачи могут отправляться на доработку или приниматься решение о выпуске стабильного или промежуточного дистрибутива системы.

Похожие статьи:

1. Проектирование бизнес-приложения: Управление требованиями
2. Проектирование бизнес-приложения: Построение архитектуры
3. Проектирование бизнес-приложения: Анализ

Я уже достаточно давно начал руководить разработкой, но начинал простым программистом. По прошествии многих лет все ощущения от работы как программиста и как руководителя успели систематизироваться. Думаю, что сейчас я готов поделиться ими.

На самой заре 90-х прошлого века я занялся программированием как хобби. Это было интересно, увлекательно. Этакий драйв. Информации по программированию было недостаточно. Были программистские журналы, были какие-то книжки, но они давали лишь пример решения каких-то специфичных задач, а зачастую вообще ничего не давали – авторы писали «мусор». Поэтому у меня все задачи, которые я себе ставил, носили скорее исследовательский характер. При решении этих задач я часто изобретал «велосипед».

Следует отметить, что желание стать профессиональным программистом сподвигло меня на поиск интересной специальности для обучения в институте (на самом деле, в университете). Мне как раз стало интересно направление систем автоматизированного проектирования (САПР) – перспективное, сложное и интересное направление. Реклама сотрудников института сработала и я поступил на соответствующий факультет. Но правда жизни оказалась не такой радужной – на факультете САПР готовили не программистов, а инженеров, которые иногда могут автоматизировать свои расчеты в этих системах САПР. Какое же это было разочарование для меня! Итогом этого разочарования стало то, что я просто бросил институт, не окончив обучения.

Ближе к концу 90-х я занялся программированием профессионально. Это не значит, что до этого я был ламером – наоборот, технические знания были достаточно высокие. Просто я стал получать деньги за то, что так нравится.

Итак, устроившись на работу я попал в коллектив программистов. Вполне понятно, что ранее полученные знания были лоскутными и не давали полной картины, как можно их применять в реальной работе на реальных проектах. Именно эту информацию мне хотелось получить у своих коллег. К сожалению, ни достаточной культуры ведения проектов, ни хороших технических знаний я не нашел – все были почти такими же зелеными юнцами, как и я (при этом контора была одним из лидеров на рынке). В других организациях ситуация была, а зачастую и остается до сих пор такой же плачевной.

В этот момент я принял два ключевых решения для себя: продолжить обучение в институте именно по направлению программирования и самостоятельно обучаться всем премудростям программирования на основе открытых источников (книги и Интернет). Сказано – сделано: восстановился в институте, но на другом факультете, и начал впитывать и анализировать информацию отовсюду, откуда только было можно.

Обучение в институте показало, что в институте не готовят профессиональных программистов. Да, были занятия, которые корелировались с программированием (правда, в таком убогом виде, что это невозможно применять в реальности), а по методологиям разработки, можно сказать, вообще ничего не было (за исключением одного из предметов, но там было все настолько обще и скудно в теории, что на практике это, опять же, невозможно применять). В итоге, успешно окончив институт, я отказался от предложения поступить в аспирантуру – не видел, что она могла бы мне дать, да и что я мог бы принести реально полезное в нашу «науку». Ну а разочарование в нашей системе образования оказалось настолько огромным, что сильно сказывается и сейчас.

С самообразованием повезло значительно лучше – я профессионально вырос, мог выполнять работу архитектора. При этом изучил различные методологии (класса Agile и Rigorous – строгие), которые стал применять и адаптировать в своей команде. Как мне кажется, я получил очень хорошие знания и научился применять на практике знания от технических до методологических. Как это часто бывает с самообразованием, часто приходилось учиться на своих ошибках, но это лучше, чем ничего.

В процессе работы я часто сталкивался с тем, что в команду приходят новые люди. Зачастую, они оканчивали хорошие институты, да еще и с хорошими оценками. Но мое понимание текущей ситуации в образовании не позволяло все принимать за чистую правду – ни красный диплом, ни громкое имя ВУЗа не давали гарантии того, что реклама соискателя на рабочее место окажется правдой. В итоге приходилось выбирать наиболее адекватных (с необходимыми техническими знаниями, со способностью обучаться и с возможностью легко и бесконфликтно встроиться в рабочий коллектив). Ну а дальше начинался долгий процесс обучения и тонкой настройки.

Отдельно расскажу о тех, кто приходил ко мне на собеседования и не получил «счастливый билет». Самооценка у соискателей очень завышена (возможно, что в этом тоже виноват миф об «отличных русских программистах»). Зачастую, приходят совершенно неподготовленные люди, получившие базовые знания о языке программирования и верящие в то, что они могут творить чудеса. При этом они не могут выполнять работу в коллективе, не могут проанализировать задачу и затребовать недостающую информацию. Так же очень часто (около 90% от общего количества) встречаются и те, кто при недостатке информации или наличии противоречий в задании выбирает собственное решение, которое не согласовывает с коллегами (иногда после такого приходится очень долго выправлять ситуацию, чтобы устранить результаты такого «творчества»).

Исходя из выше сказанного я могу отметить основные параметры, по которым можно оценивать разработчиков, а начинающим (а иногда и профессиональным) разработчикам готовиться к взрослой жизни:

1. Разработчик должен понимать, что разработка – это не только умение программировать, но и коллективная работа. От каждого конкретного разработчика зависит общий успех проекта. В данном случае действует правило: подвел один – пострадали все.
2. У разработчика должен быть внутренний стимул к самостоятельному развитию, обучению. Нет ничего хуже, если человек остановился в развитии и не пытается получать и активно применять информацию в работе.
3. Необходимо знать, какие методологии используются при разработке (класса Agile и Rigorous – строгие, например RUP или MSF). Просто знать названия недостаточно, необходимо понимание самих процессов в команде и какие документы должны готовиться при этом. Следует так же учитывать, что в каждой команде присутствует своя адаптация того или иного процесса разработки (хуже, когда ее нет).
4. Необходимо понимать, что в большинстве случаев поставленная задача или уже была решена кем-то в подобной ситуации, или при решении задачи можно использовать уже разработанное другими (дополнительные компоненты и фрэймворки). Чтобы не изобретать велосипед, необходимо посоветоваться с коллегами (может, кто припомнит какое-либо решение, свое или чужое), изучить внутреннюю документацию по проекту или поискать в Интернете.
5. Иногда определенное решение задачи может повлиять негативно на другие компоненты разрабатываемой системы. Чтобы измежать этого, требуется обязательно консультироваться с разработчиками «соседних» компонентов и архитекторами на предмет совместимости решения и системы.
6. Если разработчик делает оценку задачи, то он должен всесторонне проанализировать ее. При этом должны быть определены риски (придуманное в первом приближении решение может не удовлетворять требованиям к производительности или новая технология может сильно затянуть разработку или вообще остановить ее) и пути их устранения, основные направления решения и альтернативные варианты, каким образом будет проводиться тестирование. Часто разработчик оценивает некий идеальный вариант, даже не закладывая время на тестирование и отладку. Из-за этого он срывает сроки и подводит своих коллег.
7. После выполнения задачи любой разработчик должен проанализировать результаты своей работы и сделать выводы. Иногда, полученное решение является удовлетворительным на текущий момент, но в дальнейшем потребует переработки. Для этого можно вести список потенциально проблемных мест в решении, чтобы заранее предотвращать возможные негативные последствия, а не ждать, когда гром грянет.

Видите, что я описал параметры для разработчиков, а не программистов? Дело в том, что разработчиком может быть как программист, так и тестировщик и архитектор, одним словом, создатель системы. Ну а данные параметры применимы ко всем – они универсальны.

Вот правила, которые я стараюсь донести до каждого члена команды разработки:

1. Никогда не делайте работу сверх той, что определена заданием (я могу и не заплатить за такую «доработку»).
2. Если возникают неоднозначности или что-то непонятно, то обратитесь как можно раньше к тому, кто помог бы разрешить все вопросы (часто разработчик может неправильно «додумать» задачу).
3. После получения задания проконсультируйтесь с аналитиком или другим ответственным за требования лицом по поводу реализации, разрисуйте полностью свое решение, чтобы всем было понятно, что в результате получится (реализация должна соответствовать ожиданиям заказчика). Когда решение согласовано со всеми заинтересованными лицами, его можно задокументировать и приложить к проектной документации.

Итак, что же такое группа? Группа – это некоторое количество людей, выделенных для решения какой-то одной задачи. В группе каждому исполнителю может ставиться индивидуальная или групповая подзадача, которая входит в основную. Зачастую, каждый член группы ощущает себя индивидуалом и стремиться к решению поставленных перед ним задач.

Команда базируется на понятии группы, но каждый член команды осознает, что поставленные перед ним задачи важны не столько для него самого, сколько для решения единой общей задачи, поставленной перед командой.

Очень часто руководители ограничиваются созданием группы и не мотивируют создание единой команды. Это зачастую чревато огромной неэффективностью работы членов группы из-за плохой мотивированности на результате. В результате возможны срывы сроков, плохая коммуникация, неудовлетворительный результат и т.д.

Одной из главных задач руководителей является создание команды, т.е. мотивирование каждого члена группы на достижение поставленных задач именно перед группой. В данном случае личные результаты каждого члена группы будут менее приоритетны по сравнению с результатами группы (команды).

Что же необходимо сделать для создания команды?

1. Объяснить цели (стратегические, тактические, оперативные), которые команда достигает при решении поставленных задач.
2. Нацелить каждого члена команды на совместное решение поставленных задач.
3. Дать понимание всем членам команды того, что каждый из них является ответственным лицом за свои обязательства перед командой.
4. Обеспечить отличные способы коммуникации между членами команды (регулярные встречи, оперативные звонки и письма с оперативными ответами, частое личное общение и т.п.).
5. Дать понимание того, что в некоторых случаях исполнитель должен проявлять инициативу.

Но создание команды – это треть дела! Самое главное – сохранить ее в процессе работы. Для этого необходимо поддерживать перечисленные выше задачи в актуальном состоянии, а так же выполнять дополнительную работу:

1. оперативно решать возникающие проблемы,
2. регулярно получать состояние о продвижении в решении поставленных задач,
3. мотивировать различными способами активную работу членов команды (часто хватает поднятия морального духа сообщением о реальных успехах команды и ее продвижением в работах, так же хорошо действует персональное развитие и обучение каждого члена команды),
4. постоянно мониторить психологическое состояние каждого члена команды, предупреждая возникновение внутренних и внешних конфликтов.

По данной теме советую так же почитать статью «Группа или команда?«.

Похожие статьи:

1. Ничего лишнего