Постановка проблемы исследования

Плохой менеджмент и ошибки при проработке требований заказчика

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

В 2017 году мы начали работу над проектом Sellsay. Изначально проект казался небольшим: необходимо было лишь дополнить офлайн iOS-приложение функциональностью для многопользовательского режима. Здесь мы объяснили клиенту, что помимо мобильного разработчика, для реализации серверного функционала и панели администратора ему понадобятся бэкенд- и фронтенд-разработчики.

После первых спринтов аппетиты клиента выросли, и он стал заваливать нашего менеджера новыми требованиями, причём пытался все пожелания внести именно в текущий спринт. Наш менеджер часто продавливался, и это приводило к затягиванию срока готовой работы. Во-первых, задач становилось всё больше, во-вторых — ломалась старая логика и нарушались тест-кейсы QA-инженера.

С менеджером проекта мы поговорили, но ситуация не улучшилась, так что пришлось его поменять.

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

Замалчивание проблем в проектах

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

Примеры таких вопросов (на основе исследования ~2000 проектов):

1. Планирование без учета фактов. Деньги и ресурсы (особенно ресурсы) считаются вне существующей реальности, типа доступного на 100% бизнеса, идеального подрядчика, который сделает все сразу и вовремя. Злобная статистика: только 1 из 7 РМов в состоянии объяснить спонсору и Ко реальную ситуацию. Остальные 85% терпят фэйл, а потом наслаждаются поехавшими сроками, поисками дополнительного бюджета и прочими радостями.
2. Неучастие спонсора. Ну тут вы сами все знаете, если нет адекватного лидерского посыла и политического участия – пиши пропало. Злобная статистика: 88% РМов уверены, что вероятность убедить спонсора, что он как бы вам что-то должен – где-то между very difficult и absolutely impossible. Ну и никто обычно и не пытается, да, поэтому 75% проектов с такой проблемой терпят крах.
3. Стейкхолдеры сливаются при планировании. Требования заканчиваются на «сделайте как у конкурентов», сроки – «ну посмотрим после того, как закончим с бюджетом для акционеров», риски «нам не апрувят» и т.д. На выходе – scope creep и всеобщая взаимная ненависть. Злобная статистика: только 13% РМов признавались, что им удалось победить бизнес и научить их планировать. А те, у кого такая фигня была, и кто научить не смог, проваливают сроки и бюджет в 80% случаев.
4. Отчетов о ходе работ от участников проекта нет или они нагло врут. Без комментариев. Злобная статистика: с этим сталкивались 50% РМов, и только 1 из 4 достаточно суров, чтобы надавать всем по шапке и научить так не делать. А  что с 74% проектов, где были оставшиеся 3 РМа? Правильно, фэйл, в первую очередь в части содержания.
5. Участники проекта не справляются/тупые/ленивые/некомпетентные/им не интересно/плюют на ваш проект и едут на Филиппины/занимаются изменением пола и им не до вас/…. Ну тут, уверена, вы сами можете список продолжить. Особенно проявляется, когда амбиции проекта и спонсора/заказчика зашкаливают, а людей мотивировать в этом направлении как-то забыли. Ну или забыли РМу разрешить уволить всех к чертовой матери или дать всем премию, и он может только ходить, всех просить, всем улыбаться и быть просто красивым. Злобная статистика: такая проблема есть в 80% проектов (а вы думали, вы особенные, да?), и 4 проекта из 5 из-за этого благополучно не выживают или выживают сильно потрепанными и ни разу не в проектном треугольнике.

Тема 3. Источники информации и способы работы с ними.

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

Обработка информации для теоретической части проекта. Структура. Таблицы и схемы. Сортировка. Способы анализа собранной информации.

Практическая деятельность учащихся:

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

Подготовка шаблонов.

Задание на преобразование текстовой и графической информации в электронный вид.

Проектная деятельность учащихся:

Структура проектирования

Проектирование делится на процедуры, этапы и стадии. Проектирование сложных объектов включает стадии:

• научно-исследовательских работ,
• опытно-конструкторских работ,
• технического проекта,
• рабочего проекта,
• стадию испытания опытного образца.

Первая стадия зачастую делится на стадии предпроектных исследований, технического предложения и технического задания. Содержание деятельности на этих стадиях сводится к:

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

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

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

При некоторых видах договора подряда функцию взаимодействия с проектными организациями берёт на себя генеральный подрядчик. Международные стандарты инжиниринга предусматривают несколько вариантов, среди которых самые распространённые соглашения – это договоры в стандарте EPC (Engineering Procurement Construction) и в стандарте EPCM (+Management). В первом случае контрактор предоставляет заказчику услуги по проектированию (а также по закупке оборудования и строительству) «под ключ». Во втором случае, контрактор занимается менеджментом этих процессов (в том числе, и менеджментом проектирования).

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

Прогнозы и оценки: официальные и профессиональные

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

Между тем сами строители в целом положительно относятся к нововведениям, однако отмечают, что имеющейся нормативной базы для внесения полной ясности в этом вопросе пока не вполне недостаточно. «Использование типовых проектов значительно упрощает процесс проектирования и дальнейшего строительства однотипных объектов капитального строительства. Очень хорошо, что в Градостроительный кодекс РФ будет введено определение документации повторного применения и перечислены основные условия ее использования. Тем не менее за этим понятием стоит нечто большее, нежели тот текст, который предложили нам авторы закона», – полагает директор по науке Группы компаний «Городской центр экспертиз» Алексей Исаков. «Не следует забывать о том, что для того, чтобы типовой проект, пусть он ранее и прошел все предписанные экспертизы, стал легитимным, застройщику каждый раз необходимо будет выполнить ряд дополнительных мероприятий. Так, ему в любом случае придется предварительно осуществить «привязку» типового проекта к местности, провести инженерные изыскания, спроектировать фундамент с учетом особенностей конкретной площадки. По результатам этой работы также требуются получение экспертного заключения», – продолжает эксперт. Кроме того, Алексей Исаков напоминает, что состав проектной документации подразумевает наличие так называемых спецразделов, содержимое которых также требует экспертной оценки. К примеру, это относится к вопросам обеспечения экологической и пожарной безопасности, а также присоединения возводимого объекта к внешним инженерным сетям. А в случае модификации типовой проектной документации – ведь без этого практически невозможно обойтись, нужно еще и получить у автора типового проекта согласование. «Опыт показывает, что наверно застройщикам придется перерабатывать эти разделы каждый раз», – подчеркивает эксперт.

Начальник Департамента проектирования ООО «Мортон – РСО» Татьяна Зверева, в свою очередь, отмечает ряд проблем, которые возникают при использовании типовых проектов в строительстве социальных объектов. «В микрорайонах, где мы работаем, повторно применить типовую документацию при строительстве детских садов и школ практически невозможно. Главным образом это связано с особыми требованиями к таким объектам. К примеру, проекты каждый раз приходится приводить в соответствие с условиями размещения территории школы или детского сада на местности, с условиями инсоляции и т. д. Кроме того, постоянно меняется нормативная документация, в том числе касающаяся требований к доступности объектов маломобильным группам населения и т. д. Все это затрудняет использование типовых проектов», – заключает эксперт.

***

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

Проектирование как основа формирования любой деятельности

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

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

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

Как часть инженерной деятельности современное проектирование имеет ряд особенностей, которые отражают содержание этого процесса.

• Итерационная особенность проектирования. Объект проектирования до его воплощения рассматривается в виртуальном (идеальном, знаковом) контексте. До того, как он будет осуществлён, нет возможности создать исчерпывающее описание, поэтому неизбежны исправления и уточнения, что предполагает итерационный характер работы над проектом. С завершением каждого итерационного витка описание становится полнее и точнее.
• Коллективный характер. Проектирование сложных технических объектов и объектов строительства требует привлечения специалистов множества специальностей. Так один из самых перспективных и быстроразвивающихся подходов к строительному проектированию – 3D BIM(Информационное объёмное моделирование) – в качестве важнейшего преимущества содержит возможность различных специалистов взаимодействовать в режиме реального времени с обеспечением согласованности и безошибочности действий. Тем не менее, особенно сложные инновационные объекты с малым количеством типовых элементов создаются долго даже с учётом синхронизированной и настроенной работы коллектива специалистов. Так, например, проектным временем создания двигателя самолёта называют период в 8-9 лет. Столько же отводится на создание современного комплекса электронного оборудования.
• Типизация и унификация. Типизации подвергаются как проектные решения, так и средства проектирования.
• Многовариантность решений. Разнообразие решений обуславливает жёсткая конкуренция в условиях глобализации. Поиск новых привлекательных и конкурентных проектных решений рождает многовариантность.
• Многовариантность методов. Существуют не только различные проектные задачи, но и разные методики, технологии и алгоритмы для решения каждой из них. Отдельные методы имеют ограничения по условиям применения и по степени точности в обеспечении процессов. Реализацию разных методов помогает осуществлять вариативный поход в выборе информационного и программного обеспечения.

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

• автоматизированное проектирование, основанное на взаимодействии ЭВМ и человека,
• автоматическое проектирование, выполняемое на промежуточных этапах без участия человека,
• ручное.

Подавляющее большинство проектов пока осуществляется по автоматизированному типу, а автоматическое проектирование применимо к относительно несложным объектам. Но и в этом соотношении доля участия компьютера постоянно растёт.

Оценка проекта

Мы точно оцениваем только небольшие проекты до 1000 часов. Если проект большой, разбиваем его на майлстоуны, а их в свою очередь дробим на двухнедельные спринты. Уточняем исходные данные: погружаемся в бизнес заказчика, проводим предпроектную аналитику и на основе её данных помогаем составлять подробное ТЗ.

Однажды мы взялись за реализацию проекта Souqina. Это iOS-приложение типа Instagram, с помощью которого можно напрямую покупать вещи у блогеров, брендов и сообществ. Мы дали заказчику первичную оценку стоимости и сроков работ по проекту. Сделали это для ознакомления — чтобы он понимал порядок цен. Сразу после старта мы погрузились в проект, проводили исследования и уточняли требования. Соответственно, корректировали и бюджет, что встречало жёсткое непонимание клиента. В его голове уже жёстко зафиксировалась озвученная нами цифра. Дальнейшая работа с заказчиком свелась к спорам о каждой новой копейке, появившейся в смете. Проект мы в итоге сдали, но потратили огромное количество нервов и лишнего времени на переговоры. После этого случая решили, что это — не наш вариант.

Проект Souqina

Мы не даём оценок всему проекту целиком, если на его реализацию требуется больше тысячи часов. Сначала чётко прорабатываем все требования, на основе которых разбиваем проект на майлстоуны. Так как каждый майлстоун значительно меньше 1000 часов на одного разработчика, значит мы можем дать на него конкретную оценку и нести ответственность за сроки.

Требования к техническому заданию на разработку программного обеспечения

• полностью, чётко (инструкционно, без воды, возможности разночтения) и структурировано описывать будущий программный продукт (как должен выглядеть, как и с чем работать, каким требованиям отвечать) и процесс его разработки, чтобы у архитектора не возникало вопросов по реализации,
• исключать противоречивые сведения,
• быть юридически точным (следовать ГОСТ 34.602-89), поскольку вместе с контрактом и прочими документами ТЗ приобретает юридическую силу.

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

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

Этапы постановки проблемы исследования

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

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

Постановка проблемы – это описание сложившихся на данный момент нерешенных противоречий в изучаемой сфере. Важно сформулировать запрос в виде задачи. Можно разделить процедуру на ряд последовательных этапов

1. Предварительный. Осознание недостаточности знаний о явлении или ситуации. Потребность озвучивается в общих чертах.
2. Анализ, который включает: 

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

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

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