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

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

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

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

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

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

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. Ничего лишнего

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Проектирование бизнес-приложения: Анализ 2
2. С чего начать проектирование бизнес-приложения
3. Построение архитектуры приложений

Нефункциональные требования фиксируют параметры приложения, которые не относятся к выполняемым им функциям – это обычно какие-либо технические характеристики: ограничение на какую-либо операционную систему, технологию, требования к интерфейсу и т.п.

Функциональные требования описывают функции системы и определяют ограничения на них. Они строятся на основе ранее проведенного анализа и первоначально могут полностью соответствовать результатам модульного анализа.

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

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

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

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

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

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

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

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

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