Взаимодействие с заказчиком проекта реферат
Обновлено: 04.07.2024
Очень часто люди воспринимают правила и процедуры как атрибут бюрократии и чего-то искусственного. Всем хочется быть человеком аля Аль Пачино, который решает вопрос за счет своей личности.
И это хорошо. Менеджер должен уметь решать вопросы и договариваться с клиентом в сложных ситуациях. Но самые лучшие менеджеры имеют более ценный навык – не допускать таких ситуаций, когда надо что-то дополнительно решать.
Наши проекты относительно детерминированы. Мы не отправляем робота на Марс, не делаем лекарство от рака, не изучаем возможности мозга.
Мы просто делаем сложные веб-приложения, и я верю, что этот процесс можно детерминировать до уровня процесса создания гамбургера в Макдональдсе.
Представьте ситуацию, что вы пришли в кафе и заказали кофе. Менеджер, понимая, что у них нет сахара, говорит подождите 5 мин и бежит в магазин за сахаром. Либо договаривается с клиентом о скидке в 10%, если без сахара. Абсурдная ситуация, верно? Не должно быть такого, что в кафе нет сахара! Так почему же тогда другая ситуация может быть в нашей области?
Менеджер проекта должен максимально обеспечить проект всеми необходимыми ресурсами и процедурами.
Бизнес-процессы просто помогают ему избежать нелепых ситуаций. Конечно, надо делать скидку на сложность создания веб приложения. Но даже эти ситуации надо предусмотреть и обработать.
Пример. Всем известно, что веб-разработка представляет собой процесс, в котором есть стадия тестирования. И она нужна для выявления ошибок. Вы должны заранее предупредить клиента, что будут ошибки. И будет их вероятно много. Но это стадия тестирования, и все ошибки будут поправлены. Без этого пояснения вы рискуете получить серьезную проблему на проекте.
Клиент может воспринимать проект разработки как покупку готового продукта (например, телевизор). А это совсем другая история – готовый типовой продукт не должен содержать ошибок. А если содержит, то производитель его отзывает. Сайт-стартап – это постоянное развитие и улучшение продукта. Баги могут появляться на стадии эксплуатации, и самое важное – это ваша скорость в их обработке.
Теперь вернемся к формализации отношений с заказчиком. У вас должны быть выработаны свои ряд процедур, согласованных с клиентом. Вы должны четко прописать взаимодействие с заказчиком и самое главное – ознакомить его с этими правилами. Их цель – уменьшить количество проблем на проекте.
Самая простая процедура – это прием ошибок от клиента:
– как принимать – например, на определенную почту (а не в скайп менеджеру!)
– в каком формате – обязательно URL, скрин и краткое описание что не работает.
– в случае критичных ошибок звонить на эти телефоны по порядку xxxxxxxx, xxxxxxx
Самое важное – не просто прописать доку, а добиться того, чтобы клиент действительно это делал.
В некоторых случаях потребуется дополнительное обучение клиента. Например, не каждый клиент умеет делать скрины. А кто-то не понимает что такое URL (ну это же не про вас, верно?).
Выработайте сейчас для себя ряд мер и процедур, которые улучшат ваше взаимодействие с клиентом на проекте.
В каждом стартапе есть свои проблемы. Некоторые развиваются очень быстро, а некоторые могут месяцами сидеть и потом внезапно выстрелить. Изучите статью про негативные факторы стартапа, чтобы заранее предупредить возможные проблемы в своих начинаниях.
Успех проекта во многом зависит от эффективности вовлечения в процесс разработки всех заинтересованных сторон. Введение формализованных механизмов, учитывающих специфику процессов и особенности организации компании, позволяет оптимизировать организацию взаимодействия как между отделами, так и между сотрудниками внутри команд.
Каждый из нас хотя бы раз попадал в ситуацию, будучи приглашенным на некое проектное совещание, но с трудом понимая, зачем его сюда позвали. Вы безуспешно пытаетесь вникнуть в суть обсуждаемых проблем, но в результате просто тратите впустую свое и чужое время. Или, например, вы разработали дизайн продукта, но неожиданно оказывается, что документ надо было согласовать с кем-то еще, помимо непосредственного начальника. В результате принятие документа затягивается, что негативно отражается на сроках поставки продукта и, как следствие, на отношение заказчика к проекту. И наконец, представьте ситуацию, когда на момент поставки выясняется, что не было учтено важное требование, так как его заранее не согласовали с одним из представителей заказчика — а это снова аврал и срыв сроков.
Введение формализованных механизмов учета всей специфики взаимоотношений в проекте позволяет сделать работу эффективней, по крайне мере, так произошло в Санкт- Петербургском центре Motorola.
Механизмы вовлечения в работу
Заинтересованные стороны, участники (разработчики, акционеры и др.) проекта — это не только команда и заказчик, но и представители всех поддерживающих отделов (системные администраторы, группа качества, отдел логистики, бухгалтерия, отдел по работе с персоналом, тренинг), без своевременного привлечения которых реализация проекта ставится под угрозу. Для формализации процессов взаимодействия между всеми этими участниками можно использовать механизм — матрицу, определяющую минимально необходимый состав участников проекта, в той или иной роли задействованных в нем на протяжении всего жизненного цикла разработки.
На выходе каждого этапа проекта имеется рабочий продукт (work product) — документ, набор тестов или код, проходящий проверку качества, предусматривающую обзор/инспекцию, аудирование или тестирование. В таблице 1 приведена матрица для процедуры инспекции.
Такой же механизм применяется и для вовлечения заинтересованных сторон в различного рода собрания проектной команды с целью контроля изменений в проекте, определения статуса проекта и предотвращения проблем/дефектов.
Механизмы в действии
Конкретные примеры применения механизма матрицы демонстрируют, каким образом с его помощью удается эффективно вовлекать участников проекта в различные виды активности.
Инспекции документов. Таблица 2 иллюстрирует пример вовлечения заинтересованных сторон к инспекциям двух различных документов: проектного плана и процедур системного тестирования.
Обзор плана должен быть проведен представителями нескольких подразделений — это один из важнейших документов проекта, потому что именно в нем указываются задачи и цели проекта; распределение ресурсов; используемые механизмы и процедуры разработки ПО; способы взаимодействия между подразделениями; оценки объема кода и трудозатрат. Процедуры системного тестирования — это технический документ, и его должны проверять команды разработки и тестирования.
Проектные собрания. Собрание, посвященное началу проекта, является первым мероприятием, на котором собираются все заинтересованные стороны проекта. Представители всех отделов участвуют в собрании или информируются о его проведении. Здесь обсуждаются следующие вопросы: масштаб и длительность проекта; необходимые ресурсы для проекта (персонал, аппаратное и программное обеспечение); необходимость командировок; способы взаимодействия с заказчиком; вовлечение представителей отдела качества; необходимое обучение для персонала; возможность найма субподрядчиков; условия поставки; технологии; множество других аспектов, касающихся проекта. На этом этапе выявляются возможные проблемы и ставятся задачи. Именно из-за столь широкого перечня решаемых вопросов необходимо присутствие и оповещение представителей не только проекта и подразделения, но и смежных отделов. На собрании, посвященном вступлению проекта в фазу разработки, обсуждаются сугубо технические вопросы, поэтому нет необходимости привлекать к этому мероприятию такое же количество стейкхолдеров, как в предыдущем случае.
Проверочные списки. При передаче кода от разработчиков в отдел тестирования необходимо заполнить проверочный список, позволяющий проверить, что все необходимые отчеты по разработке продукта составлены; сопутствующая документация была проинспектирована; процедура хранения кода определена; связи между требованиями к продукту и тестами установлены; количество найденных дефектов не превышает нормы. В заполнении и подписании данного списка должны участвовать как сторона разработки кода, так и представитель тестовой команды. Перечень участников указан в проверочном списке, что позволяет передавать работу с одного этапа на другой.
Поставка продукта. На этапе поставки готового продукта заказчику необходимо разделять два вида поставок, промежуточную и конечную, на которых проходит проверка качества, но глубина проверки в этих случаях будет разной. Очевидно, что для промежуточной поставки проверка будет менее масштабной, а некоторые проверки необходимы только для финальной поставки, — например, проверка пользовательской документации; проверка отчета по тестированию (имеется ввиду полное тестирование); валидация инсталляции продукта; проверка того, что вся проектная документация была доведена до конца. Глубина проверки и уровень ответственности влияют на количество вовлекаемых участников (Табл. 3). Для поставок мы используем процедуру инспекции и соответственно механизм матрицы для вовлечения всех заинтересованных сторон.
Механизмы матрицы и проверочного списка — часть организационного процесса по разработке ПО в Центре Motorola, они связаны с шаблонами большинства документов, поэтому влияние изменений процесса на механизмы тщательно отслеживается, что позволяет адаптироваться к любым изменениям. Оба механизма реализованы на базе Excel, что позволяет применять фильтры и связывать с базами данных.
Читайте также: