Как лучше всего разрешить клиенту участвовать в проекте?

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

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

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

  • во-первых, показывая существующую схему базы данных и, в качестве примера, расширяя ее,
  • затем, показывая некоторый пример кода и написание нового бизнес-процесса для улучшения схемы.
• Код в настоящее время находится во внутреннем хранилище Subversion. Несмотря на то, что мы могли бы настроить общедоступный или один в его сети (к которому мы можем подключиться через VPN), я считаю, что распределенная система будет работать лучше. Однако я, похоже, единственный, кто так считает, поэтому я мог бы использовать несколько убедительных аргументов.

• Я не уверен, как поручить / гарантировать, что код, который работает в производстве, зафиксирован. Похоже, «х внес критические, недокументированные изменения прямо перед отправкой в ​​отпуск; теперь я пытаюсь выяснить эту ошибку, которая возникала с тех пор» бедствия неизбежны. В идеале все изменения до развертывания должны:

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

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

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

Это будет наименее любимый ответ - но, тем не менее, вот он!

Это рискованно (так же, как позволить новичку водить совершенно новую машину) - но это неплохая идея.

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

Что вам нужно сделать, это следующее:

1. Обучите своего клиента - программное обеспечение - это больше, чем код. Если они хотят участвовать, пусть они сначала рассмотрят архитектурные аспекты, проекты и так далее. Задайте им вопросы и покажите им последствия выбора, который они сделали ранее.

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

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

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

PS: чтобы дать вам понимание - я из Индии; и я знаю очень много IT-магазинов, в которых менеджмент не особо разбирается. Обычно они не возражают (даже чувствуют себя счастливыми), когда клиент вкладывает дополнительные ресурсы, чтобы проект не попал в мусорную корзину! Это прекрасно работает для них; все они идут с одним мышлением «Что ни говори, сэр!». Это не должно унижать моего соотечественника - но показать, что совместная разработка не такая уж плохая идея. В конце концов, именно то, что многие гуру менеджмента изображают как « подход Prosumer » к проблемам бизнеса.

Ой ... У вас есть правильная идея, но я видел, как это может сложиться, и обе стороны значительно страдают. Я поддерживаю такое приложение в настоящее время.

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

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

РЕДАКТИРОВАТЬ: К сожалению, этот корабль отплыл для вас, но пока не отчаивайтесь. Есть еще вещи, которые вы можете сделать, чтобы значительно уменьшить боль, которая придет. Неважно, что, убедитесь, что они ОДИН И ТОЛЬКО ОДИН МЕНЕДЖЕР ПРОЕКТА и ВЛАДЕЛЕЦ ПРОДУКТА и что этот человек связан с вашей организацией / компанией. Этот человек должен иметь возможность планировать спринты, включать или удалять пользовательские истории и назначать задачи ресурсам в вашей компании, а также в компании вашего клиента. Что бы ни случилось, убедитесь, что ресурсы разработки в вашей компании не работают отдельно от ресурсов ваших клиентов и, что еще важнее, НЕ работаютПозвольте разработчикам в вашей компании отчитываться перед своими менеджерами проектов или владельцами продуктов! Они либо воспользуются всеми преимуществами бесплатной работы, не предусмотренной договором, либо вычеркнут вас из вашего собственного проекта. Это уверенность.

С юридической точки зрения вы в основном спрашиваете: «Какой лучший способ проехать на осле с завязанными глазами через минное поле?»

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

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

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

Что касается того, как заставить это работать, то DCVS - это определенно правильный путь, если это возможно. Выбор чего-то нейтрального (bitbucket, github) может помочь. Наличие CI на месте также является находкой - труднее выходить из строя, когда все знают, что он вышел из строя на последнем коммите. Если вы можете заставить вещи развертываться через CI - то, что мы обычно навязываем поставщикам - вы действительно можете убедиться, что все изменения зафиксированы. Что касается обучения, вы рассматривали возможность соединения с клиентом на несколько дней? Это может быть хорошим способом установить боковые связи, которые вам понадобятся. В целом, лучший выбор - убедить всех, что они в одной команде. Потому что они в одной команде.

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

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

С точки зрения создания, это, как правило, в обратном порядке: Scope (который у вас уже есть) -> WBS (который у вас может быть) -> Матрица ролей и обязанностей -> SOW.

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

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

Пара других предостережений ...

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

2. Не думайте, что клиент знает вашу методологию.

3. Не думайте, что клиент разделяет работу вашей команды. (Я видел сюрпризы как вверх, так и вниз)

4. Потратьте много времени на обучение и совместное размещение.

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

6. Используйте клиента для проработки внутренней организации для вас и найдите экспертов по вопросам содержания и предметной области.

7. Использовать клиента, чтобы продать поезд своей организации.

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

Несмотря на все эти предостережения, клиенты вашей команды могут творить чудеса, чтобы приблизить вас к покупателям. Эти клиенты являются наиболее вероятными будущими ссылками. Удачи в лучшем из этой ситуации!

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