Усунення з невідповідністю культури клієнта / розробника у спритному проекті

Один із принципів спритного є ...

Співпраця з клієнтами щодо укладання договорів

... ще один ...

Індивіди та взаємодія над процесами та інструментами

Але те, як я це бачу, принаймні, коли йдеться про взаємодію із замовником, існує фундаментальна проблема:

Те, як думає замовник, відрізняється від того, як думає інженер програмного забезпечення

Це може бути трохи узагальнення, так. Можливо, є бізнес-домени, де це необов’язково вірно --- їх небагато, і все-таки між ними. Однак у багатьох областях типовим замовником є:

1. Цікавить щоденні оперативні проблеми - тактика короткого дальності ... не обов'язково стратегія;
2. Зрозуміло, що стосується лише негайного рішення;
3. Практичні мислителі, а не абстрактні мислителі;
4. Набагато більше зацікавлених у тому, щоб "виконати роботу", ніж розглянути, як рішення підтримає майбутні проблеми.

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

1. Люди, які багато думають про якість;
2. Особи, які цінують, як трошки передня робота може заощадити багато зусиль;
3. Досвідчені, аналітичні мислителі.

Тож, мабуть, існує розбіжність у культурі, яка, як правило, гальмує "співпрацю з клієнтами".

Який найкращий спосіб вирішити це?

Однак у багатьох областях типовим замовником є:

• Цікавить щоденні оперативні проблеми - тактика короткого дальності ... не стратегія;
• Займається лише негайним рішенням;
• Взагалі одновимірні, не абстрактні мислителі;
• В першу чергу зацікавлений у тому, щоб "виконати роботу", на відміну від довготривалого, якісного рішення.

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

Тож відповідь - навряд чи дивна - спілкування .

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

• Якщо ви скажете «це був би хак, що робить код менш читабельним і розширюваним» , вони кажуть «так, що б там не було» .
• Якщо ви говорите , «це буде короткий термін виправити, що дозволить зробити більш довгостроковий розвиток і обслуговування більш дорогим, а також збільшити ризик внесення помилок» , вони кажуть «ха, давайте розглянемо» .
• І якщо ви скажете, що "це рішення коштуватиме вам зараз 100 доларів, але вводиться 500 доларів технічного боргу, який ви зобов'язані погасити з відсотками рано чи пізно; ОТО таке інше рішення коштує вам 400 доларів зараз і не залишає технічної заборгованості; виберіть той, який ви хочу " , вони кажуть " зараз ми говоримо! " .

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

Розумний власник бізнесу зрозуміє - якщо ви пояснюєте їх своєю мовою - чому важливо підтримувати програмне забезпечення в чистоті, писати одиничні тести, рефактор і т. Д. Навіть незважаючи на те, що вони, як здається, безпосередньо не сприяють нічого в короткий термін, вони є важливими для тривалого обслуговування. А розумні клієнти дбають про довгострокову ремонтопридатність свого бізнесу, тому вони, безумовно, готові інвестувати в нього, коли бачать цінність, яку отримує їх інвестиція. Однак і їхні ресурси, і ваш час обмежені, тому вам потрібно розставити пріоритети та зосередитись на найважливіших речах. Але це важливо лише в тому випадку, якщо воно важливе для вас обох .

Можливо, ви захочете переробити модуль А, тому що код там просто жахливий, і у вас є приголомшлива ідея, як переробляти код, щоб бути стислим, елегантним та чистим, використовуючи шаблон дизайну, про який ви щойно прочитали. Однак якщо цей модуль не торкався роками, і він працює надійно, вам, швидше за все, краще зосередитись на модулі B, який буде продовжено на наступному тижні за допомогою дуже важливої ​​нової функції, і він містить багато помилок вже.

Як ваш клієнт бачить себе:

• У мене є проект, який мені потрібно зробити якомога швидше
• Я знаю свої потреби в бізнесі
• Мені потрібно вирішити проблему таким чином, який не буде руйнувати діючу ділову практику
• У мене є обмежений бюджет, щоб виконати це.

З іншого боку, вони бачать вашу групу як:

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

Вашою основною проблемою, здається, є те, що ніхто з вас не розуміє, що їм потрібно від іншої сторони.

Ну, і в першу чергу, Agile - це не вирішення всіх проблем, які виникають у вашому проекті.

Те, як думає замовник, принципово відрізняється від того, як думає інженер програмного забезпечення

Так. Іноді це правда. Існують навіть випадки, коли клієнти не знають, що і як хочуть (тобто вимоги не зрозумілі). Що ніколи, якщо ви спритні, ви отримуєте результат після кожного спринту (скажімо, 2 тижні), і ви отримуєте можливість отримувати відгуки клієнтів і переконайтеся, що всі знаходяться на одній сторінці. Це допомагає визначити та виправити проблеми на ранніх стадіях, що сприятиме формуванню довіри.

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

Який найкращий спосіб вирішити це?

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

Переконайтесь, що ваш власник продукту та власники акцій відвідують демонстрації спринтів і дають цінні пропозиції щодо вдосконалення товару .

Якщо у вас немає покупця у покупця, Agile може бути майже неможливим.

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

Очевидно, що у них є щоденна робота, тому справа не тільки в тому, щоб представник замовника був на них, а в їхньому керівництві - щоб на них було час.

Тож отримання згоди від керівництва на стороні замовника є ключовою для цієї проблеми

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

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

Agile допомагає вам та вашому клієнту відповісти на ці запитання.