Управление проектамиОписание онлайнкурса о курсе
 Скачать 3.24 Mb.
|
|
Система сбора необходимой информации для расширения внешних связей и обмена опытом при реализации проектов. Сбор требований это один из самых важных этапов процесса создания любой информационной системы, будь то десктопное, веб или мобильное приложение или же просто доработка уже существующего решения. Прежде, чем начать собирать требования, необходимо выявить всех заинтересованных лиц (стейкхолдеров), которые будут пользоваться системой. Чем точнее будет этот список, тем полнее будут требования. Итак, для начала, рассмотрим кто же такие стейкхолдеры. Стейкхолдерами могут быть любые физические лица и/или организации, которые активно участвуют в нашем проекте, и чьи интересы могут быть затронуты не только в процессе создания системы, но и непосредственно по завершению самого проекта. Ими могут быть менеджеры, начальники отделов, директора, любые сотрудники организации, которые будут хоть как-то взаимодействовать с готовым решением, и чьи требования (пожелания, идеи, потребности, проблемы) будем собирать. Существует множество различных техник сбора требований, которые помогут лучше понять, что же хочет заказчик. Рассмотрим основные из них чуть подробнее: Анкетирование Данный способ подразумевает под собой составление листа-опросника (анкеты, брифа), который может содержать открытые (требуют от опрашиваемого сформулировать его ответ) и закрытые (требуют от опрашиваемого выбрать ответ из предложенных вариантов) вопросы. Анкетирование используется для того, чтобы подтвердить или детализировать ранее известные требования, выбрать параметры для решений. Самым известным примером анкетирования может быть “Бриф на разработку сайта” анкета, содержащая список основных требований и информацию о будущем сайте. Преимущества: • высокая скорость получения результатов; • сравнительно небольшие материальные затраты. Недостатки: • данный метод не подходит для выявления неявных требований; • при составлении опросника физически невозможно учесть все необходимые вопросы. Интервью. Этот метод известен многим, своего рода беседа “по душам” с заинтересованным лицом, тет-а-тет. Необходимо задавать открытые вопросы для получения информации и закрытые для того, чтобы подтвердить или опровергнуть конкретные варианты требований. Данный способ применяется, в основном, для получения информации по какой-либо конкретной теме и/или для уточнения требований. Многим может показаться этот способ достаточно легким, но это не так. Провести хорошее интервью достаточно сложно. Вы должны гибко реагировать на реакцию интервьюируемого и в случае необходимости изменять порядок заготовленных вопросов или их формулировку. Не забудьте включить диктофон во время интервью или вести заметки. Из плюсов: • возможность задавать вопросы в произвольной последовательности; • возможность использовать вспомогательный материал; • анализ невербальной реакции опрашиваемого человека, позволит сделать дополнительный вывод о достоверности его ответов. Из минусов: • интервью отнимает достаточно много времени и сил; • дополнительной сложностью является получение одинаковых ответов от интервьюируемых. Автозапись Данный метод подразумевает под собой работу с записями, письмами (электронными письмами), а также с любым другим документом, автором которого является Заказчик или конечный пользователь (т.е. стейкхолдер). В действительности это может быть и документ, и наговоренная на диктофон последовательность действий или самая обычная салфетка, на которой заказчик набросал свои идеи / проблемы / «хотелки», которые необходимо превратить в полноценные требования, согласовать и передать в разработку. Примером такого метода может быть работа с концепцией или видением проекта (сам Заказчик любит называть это — «ТЗ»), которую он прислал вам на момент начала работ по аналитике. Преимущество: • помогает лучше понять сложные процедуры или процессы. Недостаток: • данный метод сильно зависит от опыта Заказчика, а также от его умения формулировать и выражать свои мысли. Изучение существующей документации Данная методика может быть использована при наличии в организации документации, которая может помочь в определении потребностей Заказчика. Примеры документации включают в себя: регламенты, описания процессов, структура организации, спецификации продукта, различные процедуры, стандарты и инструкции, шаблоны документов и т.д. Выявленные требования являются основой для дальнейшего анализа и должны быть детализированы. Данная методика применима, например, при автоматизации устоявшихся в организации регламентированных бизнес-процессов. Плюс: • быстрое получение информации. Минус: • данный способ не применим при наличии в компании только базовых документов (или при их полном отсутствии) или, если в компании Заказчика не поддерживается актуальность документации. Повторное использование спецификации. Повторно использовать спецификации можно в том случае, если есть уже завершенные один или несколько подобных проектов. Техническое задание, подготовленное на предыдущем проекте, может быть использовано для другого проекта с целью сократить продолжительность сбора, анализа и разработки требований, что позволит быстрее начать разработку. Например, ТЗ для интернет-магазинов похожи друг на друга и содержат одинаковые требования. В большинстве случаев только часть документации актуальна для нового проекта, поэтому потребуется тщательная проверка требований на соответствие текущим целям и задачам Заказчика. Преимущество: • сокращение времени на разработку документации. Недостатки: • высокая стоимость первого проекта; • излишняя детализация требований, может привести к их дорогостоящим изменениям в будущем. Представитель заказчика в компании разработчика. Один из наиболее эффективных методов сбора требований, поскольку позволяет получать от представителя Заказчика своевременную оценку прогресса, корректности реализации, в короткие сроки получать обратную связь (фидбек) и дополнительную информацию для корректировки и разработки требований. Метод часто применяется для сбора и управления требованиями при итерационной разработке, позволяет оперативно собирать, согласовывать и дорабатывать требования. В дополнение можно сказать, что наличие представителя заказчика в компании разработчика является одним из главных правил Agile. Преимущество: • быстрое получение обратной связи и информации от Заказчика. Недостатки: • достаточно высокая цена для Заказчика; • затраты по времени на адаптацию сотрудника. Работа «в поле» Работа «в поле» состоит из наблюдения за деятельностью и процессами будущих пользователей системы, и в определении требований, основанных на этом наблюдении. Если говорить проще, то это наблюдение за тем, как работают пользователи, и документирование процесса, задач и результатов их деятельности. Метод позволяет избежать проблем, связанных с трудностями стейкхолдеров в описании и выражении своих потребностей. В некоторых случаях процесс наблюдения может сопровождаться «интервьюированием» пользователей для уточнения особенностей и деталей их работы и задач. В процессе наблюдения можно так же выявить пути оптимизации бизнес-процессов Заказчика. Преимущества: • позволяет наглядно увидеть проблему и разработать наиболее оптимальный вариант ее решения; • помогает наиболее точно собрать требования, наблюдая за работой сотрудников. Недостатки: • в процессе наблюдения могут быть упущены некоторые альтернативные сценарии бизнес-процесса; • трудно применим на секретных предприятиях или опасных (вредных) производствах. Обучение. Обучение — это процесс, в котором Заказчик или любой другой человек из организации Заказчика, знающий процесс, обучает аналитика по принципу учитель ученик. Метод полезен, когда процессы и деятельность сотрудников Заказчика трудно описать с помощью других методов или Заказчик не может предоставить адекватное описание требований. Обучение позволяет лучше понять сложные бизнес-процессы, а также преодолеть трудности, связанные с нехваткой абстрактного мышления и самовыражения у будущих пользователей системы. Преимущество: • позволяет понять сложный бизнес-процесс, что позволяет предложить наилучшее решение. Недостатки: • высокая стоимость и длительность; • метод неприменим на опасных (вредных) производствах. Мозговой штурм. Мозговой штурм — наиболее часто используемый метод получения требований, которые связанны с новыми или плохо изученными направлениями деятельности организации Заказчика или функциями системы. Он позволяет собрать множество идей от различных заинтересованных лиц (стейкхолдеров) в кратчайшие сроки и практически бесплатно. Во время мозгового штурма участники «накидывают» любые идеи, касающиеся решения данной проблемы. С помощью этой методики можно проработать несколько различных вариантов решения заданной проблемы, а также разрешить конфликты требований. Плюсы: • позволяет генерировать множество (в том числе и нестандартных) вариантов решений, а также позволяет участникам развивать идеи друг друга. Минусы: • участники мозгового штурма должны быть мотивированы на идеи; • трудно применим в распределенных командах. Совещание Совещание встреча, ориентированная на обсуждение конкретных вопросов, которые были определены и озвучены участникам заранее. На такие встречи привлекаются люди, которые придерживаются различных точек зрения по текущей проблеме и могут помочь описать требования, основываясь на взглядах с разных сторон. В процессе совещания уточняется общий список требований, выявляются скрытые требования и решаются конфликты требований. Совещания являются одной из ключевых практик в Agile, т.к. в них участвуют все стороны, заинтересованные в развитии проекта и решении проблемы. Плюсы: • позволяет развить и детализировать требования, определить приоритеты. Недостатки: • сложности в организации встречи, если команда географически разделена, могут возникнуть трудности с присутствием всех необходимых людей на совещании; • консенсус необязательно будет достигнут. Use case. Use cases или варианты использования позволяют собрать и сформировать функциональные требования от лица участников Диаграммы вариантов использования определяют границы решения и показывают связи с внешними системами и участниками. Метод позволяет детализировать требования с точки зрения пользователей, а также помогает уточнить и систематизировать функционал, который требуется реализовать. Плюсы: • позволяет проработать все варианты развития сценария (основной и альтернативные сценарии) Минусы: • метод не применим для сбора нефункциональных требований. Комбинирование методик позволяет повысить эффективность сбора требований, а также избежать их «потери». При сборе требований необходимо помнить, что важны не только функциональные требования (ЧТО делает система), но и нефункциональные (КАК система это делает). Тщательно собранные требования минимизируют риски проекта, т.к. позволяют сформировать четкий и понятный базис для разработки системы. Вопрос 3. Реорганизация бизнес-процессов Понятие реорганизации Реорганизация бизнес-процессов, вопреки расхожему мнению, не эквивалентна улучшению, оптимизации и тем более реинжинирингу бизнес- процессов. Реорганизация – это изменение организации бизнес-процессов компании. На уровне компании организация бизнес-процессов – это то, где находятся границы процессов и как эти границы соотносятся с организационной структурой. Иными словами, реорганизация бизнес-процессов производится для формирования ровной и упорядоченной системы бизнес-процессов, в которой границы бизнес-процессов подогнаны друг к другу, связаны между собой промежуточными продуктами, а участники, их ответственность, полномочия и иерархическая структура – понятны и соотносятся с границами процессов. Алгоритм реорганизации. 1. Актуализация организационной структуры Реорганизация затрагивает две структуры – организационную структуру и структуру бизнес-процессов. До тех пор, пока структура бизнес-процессов не определена, она может и будет меняться по нашему усмотрению – через границы и продукты процессов. В таком случае нужно опираться на организационную структуру как на понятную и сформированную. Это означает, что реорганизация бизнес-процессов должна начинаться с ревизии участников процессов и формирования подробной оргструктуры. Процесс реорганизации начинается с ревизии организационных единиц и построения организационной структуры. Необходима организационная структура, содержащая: • Все структурные организационные единицы – департаменты, подразделения, отделы и т.д. • Взаимосвязь структурных организационных единиц. Это значит, что если департамент состоит из подразделений, а те, в свою очередь, состоят из отделов, то это должно быть отражено в организационной структуре. • Руководителей каждой структурной единицы • Должности сотрудников каждой структурной единицы. Тут важно быть точным. Если в компании есть должности «старший специалист», «ведущий специалист» и «главный специалист», то их нельзя объединять под одним названием. Это разные должности. • Количество сотрудников, занимающих каждую должность. • Подчинение сотрудников, выходящее за рамки «сотрудник отдела подчиняется руководителю отдела». • Если количество сотрудников позволяет, то можно указать конкретных людей, занимающих свои должности. В итоге должна получиться детальная организационная структура, которая позволит перейти к следующему этапу. Рис. 6.1. Организационная структура 2. Ревизия функций, полномочий и коммуникаций При выявлении процессов на основании действующей организационной структуры следующим шагом нужно выяснить – что делает каждая организационная единица, какие полномочия имеет и с кем, по каким вопросам взаимодействует. Реорганизация бизнес-процессов потребует составить список всех функций сотрудников, чтобы определить, в рамках каких процессов, эти функции выполняются. Рис. 6.2. Ревизия функций 3. Определение бизнес-процессов Все функции, которые выполняют сотрудники, делаются ради какой-то цели. Этой целью является продукт процесса, а сами функции выполняются в рамках бизнес-процессов. Эта логика позволит сгруппировать функции и выявить бизнес-процессы. Выявленные полномочия и взаимодействия организационных единиц используются для проверки состава и границ выявленных процессов. Нередки случаи, когда сотрудник забывает о тех или иных функциях, но отлично рассказывает о них с точки зрения коммуникаций. Например, сотрудник может не сказать о том, что он выполняет функцию консультирования по каким-то вопросам, однако он точно вспомнит об этом, когда будет рассматривать вопрос с точки зрения коммуникаций. После того, как определили процессы через функции, нужно сформировать карту бизнес-процессов верхнего уровня. Рис. 6.4. Карта бизнес-процессов 4. Ошибки в структуре процессов На данном этапе необходимо понять, что не так в организационной и структуре процессов. Необходимо руководствоваться пониманием того, чем является эффективный бизнес-процесс, чтобы понять, что не так в процессной структуре Продукт эффективного бизнес-процесса имеет больше ценности, чем затраты на его реализацию. В эффективном бизнес-процессе нет ничего лишнего. Эффективный бизнес-процесс выполняется единым потоком работ. Низкая или предсказуемая вариативность говорит об эффективности бизнес-процесса. Эффективный процесс может быть легко воспроизведен другими людьми Эффективный бизнес-процесс не зависит от ресурсов В процессе заложены механизмы улучшения на основе обратной связи Только управляемый процесс может быть эффективным Плановые показатели процесса основаны на лучших практиках Процесс стремится к идеальным значениям С точки зрения организационной структуры, нужно смотреть на следующее: 1. Каждая организационная единица должна заниматься своим делом. Это значит, что сотрудник не должен выполнять «кусочки» бизнес-процессов, в которых, по большому счету, он не может создать какую-то ценность. Например, сотрудник производственного отдела не должен принимать участие в процессе логистики и переживать о том, чтобы получить материалы для производства. Отдельно это касается согласования. Очень часто можно встретить, что сотрудники согласовывают те или иные документы, хотя на самом деле они не могут этого сделать. Хотя бы потому, что не обладают нужными компетенциями или информацией. Не менее часто встречается такой момент, когда сотрудники из-за загрузки в не основных для них процессах не успевают нормально делать основную работу. Это тоже будет видно при выравнивании структур. 2. У каждого бизнес-процесса есть и понятен его владелец и место владельца процесса в организационной иерархии. 3. Владелец процесса реален, а не номинален, то есть у него хватает полномочий, ресурсов и заинтересованности, чтобы управлять процессом. 4. Нет разрывов при передаче чего-то от одного процесса другому. Например, все понимают, что первичную документацию нужно сдавать в бухгалтерию (организационная единица) и что есть процесс приема и учета документов. Но как только происходит наложение одной структуры на другую, можно увидеть, что нет конкретных должностей, которые отвечают за передачу документации. Более того, может выясниться, что и в бухгалтерии нет сотрудника, отвечающего за прием и учет документации. Многие процессы протекают через разные организационные единицы, и чтобы это работало эффективно, вместе с потоком работ и промежуточными продуктами должна передаваться ответственность. Проще говоря, должна соблюдаться цепочка «поставщик – вход – процесс – выход – клиент». При этом важно понимать, что, если звено приняло что- то, оно приняло и ответственность. Это задает определенные требования к входному контролю. 5. Новая структура процессов Сложно выдать некий универсальный процесс, который бы позволил бы понять какой должна быть новая структура процессов. Каждый случай уникален. Но общие рекомендации таковы: 1. Структура процессов должна быть всем понятна. Смысл деления процессов на основные, вспомогательные и процессы управления также должен быть прозрачен. 2. Каждый должен знать, какова цепочка процессов, позволяющая производить продукт и получать деньги – цепочка основных процессов. 3. Подразделения, занятые в ключевых процессах, должны заниматься только ими – никаких размытых границ, дополнительной нагрузки и т.д. 4. Участие каждой организационной единицы в каждом бизнес-процессе должно быть кристально понятно. 5. Организационная иерархия не должна противоречить процессной. Не должно быть ситуаций, когда, к примеру, директор по HR имеет влияние на производственные процессы, а коммерческой директор заносит карточки товаров в 1С. 6. Коммуникации между участниками процессов должны соответствовать потребностям процессов и возможностям коммуникаций в иерархической структуре. 7. Не должно быть коллективной или размытой ответственности за процессы. 8. Помните, идеальный вариант – это когда границы бизнес-процесса соответствуют границам организационной единицы, его выполняющей. 9. Все структуры должны соответствовать целям, стратегии и культуре компании. 10. То, что вы запланировали на бумаге, должно быть реализуемо. 11. Соотношение процессной и организационной структур должно быть зафиксировано и доступно для всех сотрудников компании. Рис.6.7. Процессно-ориентированная организационная структура 6. Синхронизация структур Реорганизация бизнес-процессов начинается с организационной структуры и ею заканчивается – мы используем действующую организационную структуру, чтобы составить структуру процессов и привести организационную структуру в соответствие процессам. Структура процессов - приоритетна, так как именно она отражает то, как делаются дела в компании. Поэтому основные усилия по синхронизации структур будут направлены на организационную составляющую. Чтобы структура бизнес-процессов и организационная структура соответствовали друг другу, понадобится изменить несколько вещей. Изменения могут затронуть: • состав организационной структуры – могут появиться или исчезнуть отделы и должности; • количество уровней управления – оно может и уменьшится, и увеличиться. Первое – предпочтительнее; • организационную иерархию – может измениться подчиненность; • функционал структурных организационных единиц и должностей; • функционал конкретных сотрудников – чаще всего это касается руководителей высшего звена; • ответственность – в основном будет касаться управленческого состава. Чтобы изменить организационную структуру точно понадобится: 1. Выпустить положения о структурных организационных единицах (департаментах, отделах и т.д), в которых будут указаны процессы, продукты процессов, функции в рамках процессов, за которые единица несет ответственность. 2. Выпустить должностные инструкции, где помимо функций будет указано соответствие функций процессам и их продуктам (результатам деятельности). Обязательно необходимо указать ответственность и полномочия должности по каждому процессу. Инструкция должна содержать перечень ролей во всех процессах, в которых должность принимает участие. Классификация RACI здесь может очень помочь. 3. Назначить владельцев процессов в официальном порядке. Обязательно обозначить их функции как владельцев процессов, обязанности и полномочия. 4. Выпустить положение об управлении бизнес-процессами. 5. Подготовить план подготовки и согласования вышеуказанной документации. Крайне важно, чтобы план также предусматривал донесение информации до сотрудников и способ контроля – нужно убедиться, что сотрудники все поняли и согласны делать так, как написано. Подсказка – ознакомление с документом под подпись не работает. 6. Дать время на переход от старого к новому и четко обозначить, когда этот переход закончится. Это позволит сотрудникам сосредоточиться на сути и не бояться изменений, а наличие срока перехода позволит относится к данному процессу серьезно. 7. Запустить систему поощрений и наказаний, связанную с переходом. 8. Назначить конкретных ответственных и реально требовать выполнение ответственности. Самый важный момент – вся документация должна быть простой для работы и должна быть легко доступна сотрудникам. Рис. 6.8. Структура бизнес-процессов через призму организационных единиц 7. Стабилизация Проблема в том, что любая система в течение некоторого времени после изменения стремится вернуться к предыдущему состоянию. В особенности это касается людей. Поэтому изменение необходимо стабилизировать, дать прижиться новой структуре. И поэтому так важно – дать время на переход от старой структуры к новой, контролировать и управлять процессом перехода. Это тоже вопрос управления изменениями. Нужно обратить внимание на несколько базовых моментов: • Если что-то должно работать по-новому, это должно быть сформулировано, описано и задокументировано. • Документы должны быть простыми для работы – скажите «нет» формальному, бюрократическому подходу и языку. Документы должны быть понятными и небольшими. В противном случае с ними никто не будет работать. • Картинка работает лучше текста • Новые правила – новые инструкции • Все должны быть в курсе изменений и планов реализации. • Доступ к документам и планам должен быть простым. • Не ограничивайтесь документами. Учите и работайте с людьми. Проводите обсуждения и совещания. • Каждый должен понимать, что ему лично необходимо сделать для изменения и как он должен вести себя в новой структуре. Это в том числе значит, что вы должны иметь готовые ответы на вопросы, типа, «А что мне делать, если сотрудники будут продолжать обращаться ко мне по такому-то вопросу?» • Должна существовать и работать команда поддержки изменений – это люди, к которым можно обратиться с вопросами, если не понятно, что делать и как себя вести по-новому. Обратная связь должна быть обязательно • Обеспечьте заинтересованность сотрудников в изменениях. Самый лучший способ – привлекать их к процессу разработки. • Будьте терпеливы, настойчивы и последовательны. Рис. 6.9. Алгоритм реорганизации Поэтапная реорганизация бизнес- процессов Реализовать проект реорганизации сразу для всей компании непросто. Поэтому довольно часто мы выбираем поэтапный поход. В качестве этапа можно рассматривать процесс или структурную организационную единицу верхнего уровня – реорганизовали один процесс или департамент, затем пошли к следующему. Рекомендации для поэтапной реорганизации бизнес-процессов • Начинать лучше всего с процесса или отдела, задействованного в начале или конце цепочки создания ценности. • Изменения в одном отделе скорее всего затронут другие организационной единицы, но при поэтапном подходе их не получится реализовать одновременно. Поэтому у вас появятся изменения, которые будут внедряться по мере изменений других отделов. Это вносит свои особенности в проект. В частности, каждый этап будет разбит на ряд подэтапов, которые будут отражать зависимость от изменений в других отделах. • Для определения приоритета изменений отделов используйте два параметра: количество изменений, источником которых являются уже реорганизованные отделы и участие отдела в основных бизнес-процессах. • Если изменение соседнего отдела возможно реализовать относительно просто, это нужно сделать. • Постоянно сверяйтесь с картой процессов верхнего уровня. Это позволит вам не потерять лес за деревьями. • Длительность каждого текущего и следующего этапа должна быть понятна процентов на 90. Это принцип планирования «по следующим шагам». • Используйте время, отведенное на притирку к изменению, чтобы изменить зависимые отделы. Иными словами, пока в одном отделе осваивают основные изменения, измените отделы, которые зависят от этих изменений. • Найдите и используйте буферы, которые можно задействовать для временного исполнения функций. Время использования буфера должно быть строго ограничено, в противном случае нет ничего более постоянного, чем временное. Вопросы для самопроверки: 1. Опишите процесс реорганизации. 2. Что такое реорганизация бизнес-процессов? 3. Проведите сравнительный анализ методов сбора требований. 4. Какие основные направления развития продуктов можно выделить на данный момент? 5. Охарактеризуйте основные методы бизнес-планирования. 6. Опишите структуру бизнес-плана. 7. Какие существуют бизнес-планы? 8. В чем заключается разница в понятиях бизнес-план и бизнес- планирование? 9. В чем заключается особенность составления резюме бизнес-плана? 10. Что рекомендуется включить в приложения бизнес-плана? |