Який найкращий спосіб дозволити клієнту внести свій внесок у проект?

Ми будуємо CRM для клієнта. Тепер, коли перша основна фаза була закінчена, а другий був узгоджений, клієнт хотів би взяти частину робіт, зробивши незначні поправки до схеми бази даних та бізнес-процесів першою фазою, поки ми будуємо другу .

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

• До сих пір покупець не в основному бачив проект з точки зору користувача зору; Очевидно, що семінар з двох частин повинен відбутися там, де ми познайомимо його з внутрішніми роботами:

  • по-перше, показавши існуючу схему бази даних і, наприклад, розширивши її,
  • потім, показуючи деякий зразок коду та пише новий бізнес-процес для вдосконалення схеми.
• Зараз код знаходиться у внутрішньому сховищі Subversion. Хоча ми могли створити загальнодоступну або одну в його мережі (до якої ми можемо VPN), я вважаю, що розподілена система працюватиме краще. Я, мабуть, єдиний, хто так відчуває, тому можу використати кілька переконливих аргументів.

• Я не впевнений, як доручити / забезпечити виконання коду, який працює у виробництві. Здається, "x зробив критичну, незадокументовану зміну безпосередньо перед відпусткою; тепер ви намагаєтеся з'ясувати цю помилку, яка трапляється з тих пір" катастрофи неминучі. В ідеалі, всі зміни перед розгортанням:

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

  На жаль, я сумніваюся, що дисципліна для будь-якого з них буде панувати.

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

Це стане найменш улюбленою відповіддю - але все-таки ось воно!

Це ризиковано (стільки ж, як дозволяти новачкові керувати абсолютно новим автомобілем) - але це не погана ідея.

Зрозумійте, чому вони хочуть це робити: справа не в тому, що вони мають запасні ресурси, це лише змусити себе почувати себе під контролем.

Що вам потрібно зробити, це:

1. Навчіть свого клієнта - програмне забезпечення - це більше, ніж код. Якщо вони хочуть брати участь, нехай спочатку переглянуть архітектурні аспекти, конструкції тощо. Поставити їм запитання та показати їм наслідки варіантів, які вони роблять заздалегідь.

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

3. Ви можете створити окремий простір - наприклад, гілки, щоб вони мали змогу кодувати все, що завгодно - речі повинні бути належним чином перевірені перед тим, як здійснити чи злити.

Хоча я знаю, що можуть виникнути ускладнення, кожна проблема - це можливість. Якщо все піде добре, ваш клієнт насправді поцікавиться внутрішніми питаннями та виробить кращу довіру, оскільки вони знають (як) ви зробили хорошу роботу!

PS: Щоб тобі зрозуміти - я з Індії; і я знаю дуже багато ІТ-магазинів, де менеджмент насправді не має великої підказки. Зазвичай вони не заперечують (навіть відчувають себе щасливими), що клієнт вкладає додаткові ресурси для того, щоб проект не перейшов на смітник! Це чудово працює для них; всі вони йдуть з одним мисленням "Що б ви не сказали, сер!". Це не принижувати мого власного земляка - але показати, що спільний розвиток не така вже й погана ідея. Зрештою, те, що багато гуру менеджменту зображує, - це " підхід Просумера " до проблем бізнесу.

О, ти маєш правильну ідею, але я бачив, як це може бути безладно, і обидві сторони сильно страждають. Зараз я підтримую таку програму.

Дізнайтеся справжні причини, чому клієнт вважає за необхідне внести свій внесок безпосередньо в проект. Це те, що вони зараз хочуть, щоб проект було виконано швидше, ніж ви реально можете його витворити? Вони вже хочуть змін, але бояться нести додаткові витрати з вас на внесення змін у специфікації або вимагати додаткових функцій? Чи існує політична боротьба в їх організації, коли внутрішні ресурси розвитку хочуть більше контролю та вкладу в проект, або де вони шукають напруженої роботи для внутрішніх розробників? (цей останній хіт поруч із домом для мене)

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

EDIT: На жаль, цей корабель приплив до вас, але поки не впадайте у відчай. Є ще речі, які ви можете зробити, щоб значно зменшити біль, який буде надходити. Незважаючи ні на що, переконайтеся, що їх ОДИН І ТІЛЬКИЙ ОДИН МЕНЕДЖЕР ПРОЕКТУ та ВЛАСНИК ПРОДУКТУ та що ця людина асоціюється з вашою організацією / компанією. Ця особа повинна мати можливість планувати спринти, включати або видаляти розповіді користувачів та присвоювати завдання ресурсам вашої компанії, а також компанії вашого клієнта. Що б не трапилося, переконайтесь, що ресурси розвитку вашої компанії не працюють окремо від ресурсів ваших клієнтів, а ще важливіше НЕдозвольте розробникам у вашій компанії звітувати перед керівниками проектів або власниками продуктів! Вони або повністю скористаються безкоштовною роботою, не охопленою договором, або вилучать вас із власного проекту. Це певність.

З юридичної точки зору ви в основному запитуєте "Який найкращий спосіб їздити на ослін із зав'язаними очима через мінне поле?"

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

Хтось, хто зазвичай перебуває в ролі клієнта, кудись примкнув. Я, чесно кажучи, не мав би цієї проблеми, тому що якби це дійшло до цього, ви опинилися б у моєму контролі джерела, використовуючи мої настройки CI та налаштування QA для тестування речей. Цю домовленість може бути досить складною для налаштування - я отримую багато відштовхувань від консультантів, особливо для того, щоб робити справи. Здається, обробка інтерес викликає оплачувані години.

Я думаю, що ваш погляд досить чесно дещо перекошений. По-перше, майте на увазі, що це не ваша база коду, а скоріше наша база даних. По-друге, в більшості випадків у ІТ-магазину на стороні клієнта набагато більше мотивації переконатися, що цей продукт працює як розроблений і його легко підтримувати, керувати та підтримувати в майбутньому. Відмовляючись назад, щоб виправити помилки - це не більше оплачуваних годин для нас, на відміну від більшості консультантів. Більше того, побудова речей, які легко налаштовуються та виходять з ладу передбачуваними способами, набагато важливіше, коли ви також є власником операційної сторони монети. Ви можете просто закінчити проект більш високої якості, оскільки частина співробітників розробників не обмежена оплачуваними годинами.

Наскільки, як змусити його працювати, DCVS, безумовно, є шляхом, якщо це може відбутися. Вибір чогось нейтрального (bitbucket, github) може допомогти. Наявність CI на місці також є знахідкою - складніше вийти з удару, коли всі знають, що він вийшов з удару на останньому комітеті. Якщо ви можете змусити речі розгортатися через ІС - те, що ми зазвичай мусимо застосовувати у постачальників - ви дійсно можете переконатися, що всі зміни здійснені. Навчаючись, чи розглядали ви пару днів з клієнтом? Це може бути хорошим способом встановити потрібні бічні зв’язки. Загалом найкраща ставка - це переконати всіх, хто є в одній команді. Бо вони в одній команді.

Здається, це багато питань управління, оскільки це технічне питання. Я мав справу з подібними ситуаціями як в консалтингових, так і в програмних компаніях. З загальної точки зору "Скільки вартості клієнт вийде з програмного забезпечення?" і "Скільки потрібно буде зусиль, щоб підтримати його післяпродукцію?" це насправді гарна ситуація для вас. Багато клієнтів наполягають на залученні своїх людей. Але це займе багато роботи.

Починаючи з кінця на увазі, вам знадобиться хороший Звіт про роботу . Тут буде перераховано, для чого ви на гачку, і для чого вони на гачку. Матриця " Ролі та обов'язки" - це менш юридичний документ, який описує, хто є власником кожного предмета, хто є учасником та хто просто повинен бути проінформований. Обидва з них припускають, що у вас є чітко визначена структура розбиття на роботу, яка перераховує на низькому рівні (достатньо низький, щоб оцінити), що таке кожне завдання.

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

Після того, як у вас буде чітко визначено право власності, настав час керувати кодом та середовищами. Я досить агностик щодо інструментів управління кодом. Що я скажу, це те, що важливо зробити перевірку коду для всього, що робиться хтось поза основної команди. Якщо цей інструмент ви використовуєте прапори, тим краще. Ви хочете, щоб хтось не затискав щось, що суперечить ключовим архітектурним рішенням, прийнятим раніше. Концепція "4 очі" (2 додаткові очі, що переглядають все) - це єдине найважливіше тактичне рішення, яке ви можете прийняти.

Навколишнє середовище також болісно керувати. Зазвичай у мене трапляються ситуації, коли "Ми робимо свою роботу в нашому оточенні, коли ми закінчимо це йде до вашого", і постачальник, і клієнт борються. Ваша ситуація звучить складніше. Я б радив спробувати знайти спосіб, як вони працюватимуть у вашому середовищі до завершення проекту. Якщо ви зможете знайти спосіб навчити клієнта в управлінні його середовищем (не вважайте, що він хороший у цьому), тоді ще краще.

Кілька інших застережень ...

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

2. Не припускайте, що клієнт знає вашу методологію.

3. Не припускайте, що клієнт ділиться принципом вашої команди. (Я бачив сюрпризи як вгору, так і вниз.)

4. Проведіть багато часу на навчання та спільне розміщення.

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

6. Не використовуйте клієнта, щоб він працював через вашу внутрішню організацію для вас і знаходив експертів із питань вмісту та домену.

7. Використовуйте клієнта, щоб продати поїзд своєї організації.

8. За замовчуванням залучення клієнтів до процесу вашої розробки змусить вас думати як про професійну фірму з обслуговування. Девід Мейстер написав найкращу книгу на цю тему. Навіть якщо для вас стосується лише 20%, варто прочитати.

Незважаючи на всі ці застереження, в тому числі клієнти у вашій команді можуть творити чудеса, щоб наблизити вас до своїх покупців. Ці клієнти - це найімовірніші майбутні посилання. Удачі в тому, щоб зробити найкраще в цій ситуації!

Ваш клієнт обов'язково повинен ознайомитись із тим, як все налаштовано, це повинно було бути вимогою для виходу з нього на першій фазі. Вам слід наполегливо дозволити вашому клієнту безпосередньо редагувати що-небудь, він повинен заповнити запит на зміну, який вводиться у вашу систему відстеження випусків і надає пріоритет іншій роботі. Ви самі та Ваш клієнт вирішуватимете, які запити виходять за рамки договору. Як це відбувається, слід створити якийсь робочий процес / документ управління змінами, якщо такого не існує, я настійно пропоную створити його і змусити свого клієнта погодитися, що це процес, завдяки якому він може змінити речі, і отримати це в написання. Інакше не можна багато чого зробити, крім молитися, нічого не піде не так.