Якщо ви пообіцяєте доставити функцію, в якій ви не впевнені, чи реалізована вона?

У статті HN я натрапив на наступну пораду:

Завжди кажіть своєму клієнту / користувачеві "так", навіть якщо ви не впевнені. У 90% часу ви знайдете спосіб це зробити. 10% часу ви повернетесь і вибачитесь. Невелика ціна, яку потрібно заплатити за основний особистісний ріст

Але я завжди думав, що слід зробити аналіз техніко-економічного обґрунтування, перш ніж робити будь-які обіцянки клієнту / користувачеві, щоб вони не були введені в оману в будь-який момент. За яких обставин слід застосовувати вищезазначені поради?

Це друге питання, яке викликає коротша послідовність цієї статті.

• Хороший програміст: я оптимізую код. Кращий програміст: я структурую дані. Кращий програміст: в чому різниця?
  Для цього є ще одна назва: передчасна оптимізація.

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

• А тепер, завжди кажіть своєму клієнту / користувачеві "так", навіть якщо ви не впевнені. У 90% часу ви знайдете спосіб це зробити.
  Це теж неймовірно погана порада.

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

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

Подумайте про це так: Як ви думаєте, що трапиться з авіапромисловою галуззю, якби 90% всіх посадок літака були успішними? Як ви думаєте, повернення і вибачення за 10%, які зазнали аварії, вирішили б щось?

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

Клієнт поважатиме вас, якщо ви чесні. У пораді у питанні людина помиляється 10% часу. Якщо я працюю з кимось, хто звичайно помиляється один з кожні десять разів, я взагалі не збираюся йому довіряти. Це жахливий досвід.

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

Це питання було вивчене офіційно і вирішується спільно створеним кодексом етики IEEE Computer Society / ACM .

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

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

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

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

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

Існує історія з ранніх днів суперкомп'ютерів, коли Сеймур Крей та команда Control Data Corporation були близькі до запуску продукту, а інша дуже велика комп'ютерна компанія повідомила своїх клієнтів, що він також був близький до запуску. Брехня коштувала CDC багато бізнесу і перетворилася на позов, коли велика компанія не могла показати жодних достовірних доказів своїх вимог. Результатом стало те, що в той час було великим врегулюванням вартістю 80 мільйонів доларів 1970 року (близько 223 мільйонів доларів у 2012 році, з урахуванням інфляції). Про це можна прочитати тут:

http://en.wikipedia.org/wiki/Control_Data_Corporation#CDC_6600:_defining_supercomputing

З урахуванням достатнього часу, ресурсів та гнучкості навколо визначення успіху все можливе. Приклад білого x-маси простий, якщо ви хочете лише краще, ніж 50% точності, і у вас є географічне розташування користувача та трохи статистичних даних.

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

Чи додає ця функція достатню цінність, щоб гарантувати витрати на спробу?

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

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

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

Граючи захисника диявола

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

Перед тим, як розробка навіть починається, клієнти починають формувати думки про результати роботи команди, виходячи з рівня їх впевненості та готовності до виконання зобов'язань.

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

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

Припустимо, що замовник повинен вибрати один з двох сценаріїв:

Підрядник A :

• Впевнені, що вони можуть доставити на всі запити
• Результат: 90% доставлених запитів
• Замовник задоволений тим, що підрядник доклав 100% зусиль
• Замовник розуміє, що незавершені запити були пов'язані з непередбаченими проблемами, які, ймовірно, поза контролем підрядників

Підрядник B :

• Покладається на доставку 90% запитів. Не впевнені, що можуть доставити на решту 10%
• Результат: 90% доставлених запитів
• Замовник розчарований, що підрядник не намагався виконати інші 10% своїх запитів
• Замовник припускає, що невиконані 10% запитів були пов'язані з відсутністю зусиль або можливостей підрядника

В обох сценаріях було доставлено однакову кількість запитів; однак замовник відчув, що "перевиконання" Виконавця A докладає 100% зусиль і використав це для підтвердження того, що інші запити справді були складними, на рахунок підрядника A.

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

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

Ви повинні сказати їм, щоб вони дали вам час на створення "рішення шипа" .

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

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

Ось що говорить документація про програмування eXtreme :

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

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