Перестаньте слухати клієнта, щоб зробити його щасливішим

Мене звати В’ячеслав Муха, я Software Engineer‎ в MEV. Сьогодні на прикладі одного з кейсів нашої компанії я хочу розказати, як продуктова культура в аутсорсі може покращити процес онбордингу клієнтів, а відмова наосліп втілювати всі вимоги замовника — зробить його щасливішим, та на чому потрібно сфокусуватись, щоб в результаті вирішити бізнес-проблему.

Who is who в цій історії

Одного разу до нас, за рекомендацією свого товариша (нашого замовника), звернувся власник невеликої логістичної компанії у США, яка займається вантажними перевезеннями. З часом керівництво зрозуміло, що недоотримує значну частину прибутку — багато машин повертаються порожніми із кінцевої точки подорожі, а могли б додатково завантажуватися по дорозі назад. Однак для цього диспетчери мають своєчасно знаходили відповідний вантаж.

Тому, виникла ідея розробити платформу, яка б вирішувала ці завдання, а саме:

  • активно моніторила доступні замовлення на перевезення вантажів;
  • зіставляла ці замовлення з радіусом поточного місцеперебування вантажівки (або з місцем, куди вантажівка має доїхати);
  • відправляла пуш-сповіщення диспетчеру або водієві про відповідні замовлення.

За наявних умов, перше, що спадає на думку — розробка мобільного застосунку. Власне, його клієнтові й пропонували інші компанії, до яких він вже встиг звернутись — проєкт на 5-8 місяців з бюджетом понад $100 000. І саме з запитом на наш естімейт розробки такого застосунку клієнт звернувся до нас.

Але, як казав мудрий дядько Дейв Воша:

«Уважно слухай клієнта, коли мова йде про проблему, проте перестань слухати, як тільки мова йде про реалізацію.»

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

Перші кроки — перевірка концепції

Традиційно, ми почали з перевірки концепції всього проєкту (PoC) та створення прототипного рішення. Чому це вдалий перший крок при роботі над проєктом?

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

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

Подальша реалізація — фокус на швидкість та зворотний зв’язок

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

Для прикладу: навіть базу даних не підключали на ранніх етапах, а використали просто файлову систему. Проте застосували бібліотеку (tingodb), яка пропонувала MongoDB-like інтерфейс, що дало змогу без проблем переїхали на повноцінну MongoDB, коли була нагода.

Це все ілюструє два важливих моменти:

  • не забуваємо про принцип KISS (Keep It Simple Stupid), особливо на ранніх стадіях розробки системи;
  • тримаємо в голові big picture vision, стимулювати розробників спрямовувати архітектурні рішення в правильному напрямі, аби система завжди була в стані, готовому до змін.

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

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

Last but not least — увага до беклогу

Логічно, що чим більше зворотного зв’язку ви отримуєте, тим швидше розростається беклог — під кінець роботи над проєктом кількість фіч, які з’явились на основі такого фідбеку, сягнула 70%. Тобто +70% до початкового скоупа робіт.

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

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

Взято звідси: Agile Product Ownership in a Nutshell

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

Happy End

На початку статті ми говорили про те, що відмова наосліп втілювати всі вимоги замовника може зробити його щасливішим. То чи вдалось цього досягти? Думаю, кращою відповіддю на це питання проілюструє той факт, що ми змогли розв’язати проблему клієнта за 2 місяці, замість 5-8 місяців, які називали інші компанії. І головною причиною цього було те, що ми змінили сам концепт проєкту.

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

Висновки

  • Розпочинайте з аналізу та проєктування прототипу рішення. Це показує, чи ви зрозуміли завдання бізнесу та зможете його вирішити. А у більшості випадків — це ще й суттєво пришвидшить підписання контракту.
  • Рухайтесь швидко, але тримайте в голові big picture vision. Не варто інвестувати купу часу на сетап процесів та інструментів, які хоч і зручні та пришвидшують розробку, та все ж не виправдані на ранніх стадіях, особливо для невеликих проєктів.
  • Прагніть до швидкого фідбеку. Не завжди вдається одразу зрозуміти клієнта повною мірою, та й клієнт не завжди досконало розуміє, що йому потрібно. Короткі ітерації в реалізації проєкту дозволять уникнути цих непорозумінь. А в ідеалі, якщо особливості проєкту це дозволяють, варто дати слово реальним користувачам якомога швидше. Саме вони найкраще пояснять, що саме потрібно продукту.
  • Не забувайте про принципи Agile. Зокрема в тому, що особистості та їхні взаємодії важливіші, ніж процеси та інструменти, а співпраця із замовником важливіша, ніж контрактні зобов’язання.
  • Тримайте в фокусі постійну пріоритезацію беклогу. У форматі швидкого ритму та великої кількості зворотного зв’язку доводиться постійно уточнювати пріоритезацію, комунікуючи з клієнтом, над чим потрібно працювати саме зараз, а що може зачекати, враховуючи цінність задач та вартість їх реалізації.

Сподобалась стаття? Натискай «Подобається» внизу. Це допоможе автору виграти подарунок у програмі #ПишуНаDOU

👍ПодобаєтьсяСподобалось26
До обраногоВ обраному1
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Перестаньте слухати клієнта, щоб

галера втратила клієнта, а ви роботу :D

Це зазвичай зовсім із іньших першопричин стається. Частіше за усе — софт зробили і контракт скінчився, усім дякую. А так головна причина провалів, як на мене — овербеджет, дуже часто коли йдуть прямо по закону Брукса, тобто гасять пожежу бензином — коли програма вибилась з графіку через занадто амбітні цілі, невірний бізнес аналіз чи управлінський хаос: системні кризи та втрату керування. Як часто це стається? — Та блін постійно, і як ніхто клієнта не спинить від самогубства — а навпаки будуть надувати кулю додаючі по 15 новачків, тим швидше буде овербеджет. Через якусь лайку і’чи прищімлення чогось его, не проект закривають — а міняють когось із людей на проекті.

та я пошуткував просто :D

головна причина провалів, як на мене — овербеджет

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

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

Бачить програма відстає від графіка

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

Більш розумний метод масштабування програми

Наймати окремих людей і будувати команди самому, включаючи soft skills interviews. Мотивація людини на аутсорсі зовсім інша ніж у продукті (в першу чергу фінансова), відповідно і будь-яке право приймати рішення на нулі через гори бюрократії.

P.S. Взагалі клієнт щасливий коли він отримав усе позавчора і безкоштовно.

Завжди є безкоштовний опенсорс. Але, як кажуть про Лінукс: він безкоштовний тільки якщо ваш час нічого не коштує!
Більшість людей із задоволенням заплатить професіоналу, який зробить добре і швидко, аніж заощадити гроші і потім роками страждати.
Хіба ви не щасливі, коли прийшов майстер і за годину усе вам полагодив? Так — це коштувало грошей, але вони саме для цього і є!
Як каже мудре єврейське прислів’я: «Якщо проблему можна вирішити за гроші — то не проблема, а просто витрати!».

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

Підхід гарний і, в більшості випадків, є найбільш ефективним.

Але клієнту треба сказати щось аля «Схоже на те, що ми можем спробувати, але хз що з того буде. Давайте ви нам заплатите за ± 1-2міс для того щоб потестували ідеї, а потім побачим.»

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

От би хто написав статтю англійською для клієнтів: «Не годуйте українських торговців людьми!»
Щоб донести до клієнтів, що якщо вони платять за «гепа-часи» чи «хом’ячків», «тушки», «голови» — то вони завжди будуть отримувати процес замість результату!
Бажаєте побачити наскільки українці талановиті, креативні та професійні? — працюйте виключно по Fixed Price моделі. Платіть за вирішення своєї задачі — і побачите як її вирішать краще і швидше, ніж ви сподівалися! Не хочете переплачувати? Влаштуйте тендер — і обирайте краще рішення.
Але ніколи не ведіться на Agile і bodyshop моделі. Ви робите свій бізнес заручником шахраїв, єдина мета яких «видоїти» вас до нитки.
Що робити, якщо ви спокусилися на обіцянки галер і навіть вже віддали купу грошей у обмін на ледве-живу систему, яка кожного місяця потребує більше грошей аби не вмерти?
У вас є три варіанта:
1) Продовжувати грати за правилами шахраїв. Кожного місяця платити усе більше за усе гірший сервіс. Доки у вас не закінчаться гроші — і тоді усе закінчиться погано. Скоріш за все ви останетесь винні їм гроші, вони не заплатять команді яка потім буде ненавидіти вас і нищити вашу репутацію.
2) Визнати що ви придбали «мертву конячку» і краще її викинути прямо зараз аби не втрачати ще більше. Ви звільнитеся від шахраїв, але грошей на заміну у вас не буде — отже ви втратите бізнес і клієнтів.
3) Зіграти на випередження! Українська команда, яка на вас працює — такі самі заручники шахраїв, як ви! Як мінімум половину грошей, які ви їм платите — забирає галера — посередник. Скоріше за все їх примушують робити овертайм аби виконати нереальні обіцянки. Вони вимушені завжди нехтувати якістю — за що ви потім справедливо їх клянете! АЛЕ ви в змозі розірвати ці ганебні відносини — позбутися посередника — «работорговця». Візьміть команду до себе — і це будуть ваші люди! Залиште тих, хто готовий рятувати і підіймати ваш бізнес — і вони усе виправлять і врятують за ті самі гроші, які ви віддали би шахраям!
Зараз дуже легко працювати з українцями напряму — вам не треба нічого, крім «паперової роботи»: не треба офісу, не треба відкривати компанію в Україні. Вам зовсім не потрібні посередники — працюйте напряму з професіоналами і платить тільки за результат!
Позбудемося торгівлі людьми в ІТ разом!

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

Так і має бути! Це тільки на галерах продають рабів клієнту. Якщо продали — то вже сиди і не дивися у боки.
Fixed price — клієнт платить за результат. Отже компанія сама вільна обирати склад команди! Зазвичай проект стартують синьори, приймає участь архітект, а через кілька місяців, коли архітектура вже стабілізувалася — можна забирати більшість синьорів і архітекта на новий проект. Ближче до релізу девелоперів буде меньше, ніж QA.
А от підтримку буде робити інша команда — мало хто з девелоперів, хто полюбляє розробку нового, захоче сидіти на сапорті. Але це не проблема — бо нормальний проект включає прозорий код, технічну документацію і інструкції з онбордінгу.

На супорті, можна і весь проект переробити від того, що заклали «архітекти» коли задумували. Бо сурова реальність вносить свої корективи — то туди неможна нову фітчу додати, то воно не тримає навантаження в пікові години тощо. Той самий Amazon — 6 разів цілком переробляв архітектуру. ІМХО спроектувати добру технічну систему не маючі досвіду експлуатації неможливо. Ви зможете лише відтворити, скажімо по книжкам від архіткктів Amazon та документації AWS, чужий дизайн. Через схожість задач — може працювати, а може і не працювати чи бути занадто дорогим в обслуговуванні тощо.

А Time & Material — ніби щось іньше ? Погодинка це був такий собі спосіб убезпечити себе від уявлення клієнта, себе наступним Гейтцом чи Цукербергом і самостійно менеджети проект і технічний дизайн. Чи можна таким чином відповідати хочь за якийсь результат, коли від початку невідомо наскільки менеджери і техліди клієнта професійні взагалі ? Тут як пощастить інколи так, та це інколи дуже не завжди. Тому і йдуть на погодинку і навчають людей «консультувати». А це як я бачу клієнтів, що думають після військової пропаганди холодної війни — 6ісить. Вони думають тут чиста Боснія із фільмів Куштуриці чи сільська Індія , країна максимум із 18-го сторіччя, з найвищім рівнем науки і техніки достатнім для побудови вітрякового млина чи найпростішого парового двигуна. І це як по типу аборигени в шкурах і з кам’яними сокирами починають втирати свої примітивні вірування вищій рассі. Мелять дурниці про якісь: TDD, CI/CD, закриття Technical Depth і взагалі XP. Що зулуси взагалі можуть про це знати ? От через це і почала прогресувати система з погодинкою, яка справді переросла у відверту стагнацію і деградацію. Менеджерами, тобто керівниками дуже часто стають люди і без технічної освіти і без досвіду роботи як такої. Це Ок — коли починають скажімо із молодших бізнес аналістів і ростуть. Так ні — одразу в старші офіцери. По суті винаймають стюардесу чи стюарта із доброю англійською, чи іншою іноземною мовою, щоб клієнту було приємно спілкуватись. Толковий менеджер рідше виключення аніж правило (хоча є такі і їх не так і мало). Те саме 23 літні сініори та архітекти, клієнт вимагає щоб йому за ті гроші мегаскілових чуваків давали — йому їх і малюють з молоді, чи ще когось підсовують, бо де взяти таку кількість, враховуючі постійну еміграцію скілових людей? І далі по ланцюжку. Так T&M — справді бічь індустрії. Та відмовитись дуже шкода, бо воно несе гроші.

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

«галера-шахрай» скоріш за все програє якщо буде втупу продавати години і мати підписаний акти прийому передач як основний KPI

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

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

Fixed price — то, зазвичай, обман ... або обман виконавця, або обман замовника ... що саме стає відомо в кінці проекту.

Не знаю, якими проектами ви займаєтесь, але в моєму досвіді, на старті, ні замовник, ні виконавець поняття не мають, що то має бути. Оцінка проекту для fixed price — то пальцем в небо.

Та й, потім, дискусії на тему «що ж входить в той фікс, а за що платити окремо».

На фікс можна працювати лише, коли робиться «серійний проект» однаковий, вже не першому клієнту.

А в чому саме обман?
Якщо домовленність є на деякий визначенний об’єм задач за деякі гроші. Тут все чесніше нікуди. Чесніше ніж T&M.
Спроможність виконати зобов’язання це інша тема.

Я був частиною кількох великих fixed ptice, і, зазвичай клієнт не розуміє за що в нього просять 10 мільйонів на старті, а потім вичавлює максимум за ті гроші, які заплатив. Дуже складні проекти, навіть в форматі agile with cap, бо клієнт сам не може спланувати фічі на рік вперед, а допомогу не приймає, бо, дивись вище, для нього то дика сумма і довіра втрачається

Може ви клієнту продавали все що йому не потрібно. Накрутили калуд, кубернетіси 1000 годин девопсів, ліцензії та інше. А йому просто потрібно було запустити тестову версію онлайн-магазину (це реальний кейс) на no-code платформі. Тобто якщо розмова йде про такі суми та таке нерозуміння клієнтом цінності цих інвестицій мабудь або ви клієнту не те що треба пропонуєте або треба проводити роботу з менеджмента очікувань клієнта.

Я був частиною проектів де стаффили не ясно навіщо 30 чоловік та робили мікросервіси та купу проблем з інтеграциями та калудом хоча 5 синьйорів це зафігячіли би в моноліті у рази швидше. та вже було б у продакшені. І навіть цей солюшен витримумвав усі б NFR.

То відома проблема що архітектори архітектять там, де просто робити треба з гівна та палок.

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

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

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

Далі сценарії:
1. Виконавець посилання на форму зробив, але реєстрація не працює. (Ну не вписався в бюджет — не зробили, але згідно ТЗ — все норм). Клієнт: ???

2. Форму зробили, все працює: email, пароль, підтвердежння email-а.
2.1. Клієнт: а де реєстрація через fb?
2.2. Клієнт: а де капча? Тут вже всю базу заспамили боти.
2.3. Клієнт: а чому не запитується номер телефону і не висилається смс? Хто, взагалі, сьогодні email-ом користується?
2.4. Клієнт: а де «забули пароль»? У всіх є, а тут нема. Це ж «стандартна штука».

... ну я думаю логіку ви зрозуміли. Ви можете сказати, що ТЗ погано написали. Але проблема не в цьому. Розробка та оцінка дууже детального ТЗ, інколи, може займати дорожче ніж розробити сам проект і потім його раз переробити. Та й спробуйте реалізувати «інтернет-магазин» по ТЗ, де лише форма реєстрації буде описана на 10 сторінках :)) Уявіть скільки в тому ТЗ буде логічних помилок.

Ну ось, виконавець оцінив реєстрацію в 10 годин роботи (треба ж конкурентну пропозицію дати). А клієнт уявляє собі що там функціоналу буде, який треба писати місяць мінімум. Фікс порахували з «запасом», в 15 годин.

Як вийти з цієї ситуації з fix price?
Варіанти два: або виконавець піде в збиток на стільки, на скільки зможе собі дозволити, або клієнт отримає продукт, який йому не підходить.

Зійдуться «десь по середині» і кожен буде думати, що його обманули.

Ви описуєте проблеми неякісного бізнес-аналізу та проектної документації, а не фікс-прайс моделі.

Але загалом як кажуть досвідчені сейлзи великих компаній : по фікс прайс дійсно є ризики. Та проекти розміром більше 100к $ краще декомпозувати на окремі юніти.

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

Agile та scrum придумали не просто так. При цьому, вони by design не передбачають фіксованого скоуп-а.

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

З такою логікою, waterfall — наше все :)

Якщо ж, таки, по скраму, то оцінити можна, хіба, один спрінт. Якщо спрінт 2 міс, 10 людей по 3к — 60к ... ще трохи витрат на компанію — ось вам і 100к :)

Тільки от, часто спрінт — тиждень і команда 3 людини. Тут вже підписатись на фікс 100к... ну хз ... хіба з запасом в рази три ... інакше я б не брав на себе такий ризик.

Щодо фікс для тестового проекту — може бути: «ось вам 10к, зробіть що зможете з такою то задачею»... але, погодьтесь, що так рідко ставиться завдання.

Эджайл це сукупність фреймворків що захищають команди розробки та замовника та роблять їх відношення біль прозорими це правда.
Але фікс прайс це про ризики. Якщо у клієнта є обмежений бюдтеж він може провести тендер та обрати підрядника щоб у нього вкластись . Це ринок кожен заробляє як хоче. Тому теза про нечесність тут недоречна. Нечесно тікі не виконувати свої зобов’язання. Якщо виконавець або замовник не деталізували достатньо ТЗ то це вже їх проблеми.

В цілому, ви вірно говорите.... тільки мені здається, ви намагаєтесь натягнути на розробку правила ринку, яким він не є.

Якщо вам потрібно закупити 100 столів, ви можете оголосити тендер ... і навіть в цьому випадку, критерій вибору буде не лише ціна. Розробка софта так не продається (за малими винятками).

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

Якщо ви шукаєте бухгалтера ... скоріш за все, ви теж прийдете до Т&М.

Найбільш цікавою є аналогія з будівельними роботами. Цінники по ринку — це цінники за конкретну роботу, умовно, 300грн за м2, скажем, стяжки. Якщо ж ви питаєте скільки буде побудувати будинок ... вам порахують (зроблять оцінку)... але в кінці ви все рівно платити будете за тим, що вийде (Т&М).

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

> Це ринок кожен заробляє як хоче.
Це вірно ... тільки реальність не обдурити.
— Оцінки в ІТ не точні, а часто дууже оптимістичні.
— Клієнти хочуть фікс і обирають де дешевше (закладено менше ризиків)
— Виконавці або закривають ризики за свій рахунок, або за рахунок скоупу.

Ви хочете «якісного ТЗ» ... вибачте, такого не існує ... навіть в NASA.

Я кажу як з досвіду це працює, а ні як я вигадав

Якщо у клієнта є обмежений бюдтеж

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

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

Хех, ... виявляється, для цього навіть термін є ... fixed price, variable scope.

ну шоб клієнта попускати і реприоретизувати, тре ще на ранніх стадіях отримувати фідбек. а як? це питання до процесів

Щоб був фідбек — треба щоб клієнт мав на основі чого давати цей фідбек, тому потрібно якомога раніше показувати результат. І цей процес має бути поставлений на рейси — щоб і клієнту і команді була зручна частота релізів/демо.

Часті випадки, коли замовники занадто занурені в бізнес, що не мають достатньо часу виділити на комунікації з командою: то не зявляють на мітинги, то не відписують на листи і тд. В таких випадках, ми зазвичай записуємо демки, а коли треба отримати відповідь на якесь питання — задати його, як колись казав колега, «ванлайнером» — запитання має бути стисле в одне речення, з запропонованими варіантами відповідей.

а як задавати питання? отут теж питання — на одну особу поставиш, воно проігнорує, коли на багатьох, то теж не факт, що буде відповідь )) бо може хтось інший не поліниться відповісти, колективна безвідповідальність.

в моїй практиці обидва підходи працювали, в залежності від процесів у замовника ))

«Уважно слухай клієнта, коли мова йде про проблему, проте перестань слухати, як тільки мова йде про реалізацію» — вся стаття однією фразою, дяка

Треба додати ще «Інколи працює правило»

Якось дивно, що логістична компанія з США аж в 2000-якомусь там році дійшла до ідеї, що непогано було б транспорт завантажувати в обидва боки, а не ганяти пів дороги порожняком. Мені здавалося, що ця ідея прийшла в голову людству десь в часи Месопотамії чи коли там придумали першого воза.

Даже если эта идея была в голове руководства с самого начала, вполне может быть что до недавнего времени стоимость ее реализации была выше чем возможная выгода от ее внедрения и использования. Например вполне может быть что на транспорте компании просто не было GPS маяков.

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

Стаття — вилами по воді. Тому що сама тема дуже риторична. Десь треба робити те за платять, десь проявляти ініціативу. Все дуже сильно залежить від ситуації.

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

а співпраця із замовником важливіша, ніж контрактні зобов’язання.

Забудьте про це, на роботі заробляють грощі. Ця «Співпраця» — це насправді виконання роботи на дурняк. Як замовник не козел і підкине чогось нового за не велику скидку (тобто ви працюєте трохи більше на якийсь процент чим за контрактом, а вам зато дають наступну роботу), чи ви самі десь налажали та покриваєте старі борги якоюсь роботою на користь замовника в свій час — то ок. Інакше вас просто лошарять — банально обманюють на грощі, крадуть рейт. Тому якраз контракти, тобто письмово оформленні зобов’язання це штука яка на сам перед прикриває вашу власну дупу. Взагалі будь які зобов’язання краше за усе формулировать письмово. Починаючи з тих самих тікетів в багтрекінговій системі, і щоб вони там були заповнені за шаблоном таким чином щоб туди неможливо було засунути нічого з гори, так само і ви виконуєте те, що там написано — і не щось не потрібне бізнесу. Коли ви відповідаєте лише за себе, то і попадаєте самі. А от як за вами команда — то вже матимете справу скажімо із плинністю кадрів, захмарним аттрішен левелом це вже має вплив на увесь бізнес. Стосунки із замовником це купи-продай і тут як і на базарі, якщо вас можуть надурити — надурять.

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

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

Питанням на питання — ключових співробітників з контактами і рекомендаціями перелічите ? Перелічите ще клієнтів та контакти контрагентів, як не важко :)

Все вам вірно написали. Це не ваш бізнес, щоб ночами заради нього не спати. Добре зробити свою справу, можливо давши пару порад в процесі, але розвивати бізнес, це власне проблема власника цього бізнесу. І якщо ви натякаєте, що от ви як раз-то бізнесом займалися, то поміркуйте над різницею в термінах «компанія-виконавець» і «компанія-партнер».
P.S. А і ще, мова йде про США, а якщо б компанія-замовник була, наприклад с тої ж Німеччини, то ще існувала б сильно ненульова вірогідність того, что замовник порадить не пхати свого носа в його бізнес-аналіз.

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

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

Стаття про те, що треба нав’язувати своє бачення того як краще і робити більше ніж вас просять.

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

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

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

До речі, ваші опоненти вам правильно опонували. А ви, замість конструктивних аргументів, питали чи є опонент бізнесменом.

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

То навішо опонувати якщо можно навчатись ?

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

а співпраця із замовником важливіша, ніж контрактні зобов’язання.

Тут мав на увазі те що в процесі розробки, більша частина описаного в SoW функціоналу не була реалізована — через те, що в процесі комунікації та зворотнього зв’язку — виникали ідеї на значно корисніший функціонал ніж той що був задуманий, узгоджений і проестімейчений. І тут погоджуюсь — аби «прикрити власну дупу» дуже важливо перед тим, як брати щось з нових забаганок в беклог, потрібно чітко прокомунікувати, давши зрозуміти що додаючи нової задачі — ми викидаємо якісь інші що були попередньо узгоджені. Все зводиться до expectation management: проговорюємо що отримаємо (чого не отримаємо) у результаті змін в першочерговому плані.

Стосунки із замовником це купи-продай і тут як і на базарі, якщо вас можуть надурити — надурять.

У цьому і проблема українських галер: вони звикли робити нає-бізнес. Можна надурити джуна і примусити підписати контракт працювати 2 роки по 3 бакса / час? — чому б ні? Можна надурити замовника і продати йому цього джуна як мідла по 15 баксів / час? — чудово! Можна робити аджайл і розтягувати таски якомога довше? — лох не мамонт. Можна робити аби-як, накопичувати технічний борг, нехтувати качество? — чудово, потім клієнт ще роками платитиме за багфікс. Можна домовитися з менеджером замовника і пилити бюджет фарбуючи «мертву конячку»? — навчимо їх робити нає-бізнес!
Ну і, звичайно, якщо можна надурити галеру — то це тільки справедливо! Працювати «зайчиком», копі-пастити код де тільки знайдеш, писати статті на ДОУ, їздити по конференціях, вести блог — аби тільки не писати код. Якщо джуна можуть продавати за синьора, то чому б синьору не працювати як джун?
Кажете можна було б працювати чесно і допомогти клієнту краще вирішити його проблему? Заробити репутацію — і потім довірять робити серйозні проекти за великі гроші? Але ж то не наш метод. «Якщо можуть надурити — надурять!» Тому треба встигнути надурити їх першим — оце по-нашому!

Ну це по всюди таке. Сходіть на базар за огірками і побачите усе те саме. Кому є діло до ділової репутації, кому на неї з Ейфелевої вежі і головне сьогодні зірвати куш і прогуляти з дівицями легкої поведінки по кабакам. Інтерес є в усіх тільки не усі міру знають. P.S. До чого тут статті на ДОУ тут я не зрозумів?

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

Це настільки нетипово для галер — що навіть не віриться.

Ми змогли розв’язати проблему клієнта за 2 місяці, замість 5-8 місяців

Тобто ви свідомо відмовилися від грошей за 3 — 6 місяців?!
Щось тут не так — може це був fixed price проект? Тоді усе стає на свої місця: якщо гроші ті самі — то звичайно вигідніше зробите більш ефективне і швидке рішення.

Так, після того, як клієнт узгодив запропонований нами SoW, ми працювали по fixed-price. Але якби ми склали SoW на мобільний додаток, з естімейтом напр. в 5-6 місяців (і відповідним бюджетом), то з високою ймовірністю проект не зайшов би взагалі — клієнт озвучував бажання швидше та без надмірних фінансових витрат вирішити бізнес проблему.

Це настільки нетипово для галер — що навіть не віриться.

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

Підписатись на коментарі