А якщо …

А якщо користувач буде працювати на телефоні без зв’язку – то давайте докрутимо підтримку offline? Або якщо користувач забажає змінити колір обов’язкових полів не формі, або якщо мусить … Надалі миттєво пропозиція цікавого технологічного рішення яке зробить добре уявному користувача у ситуації якщо що. А чи все добре коли ми частіше та частіше починаємо робити вправи “а якщо”?

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

До чого приводить в плохому сенсі потік рішень “якшо-що”:

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

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

Аргументам до ситуації як що-що стануть улюблені цяцьки інженерів. Якщо що, то в нас буде:

  • Дуже круте налаштування системи
  • Наше рішення ваще надійне
  • Наше рішення буде афігенно швидке
  • Воно буде працювати на всіх можливих девайсах
  • Наша система буде працювати в надскладних ситуаціях. Всі помруть – але наш додаток буде працювати
  • Потім будь-які доробки за напрямком Х та Y будуть краще зроблені

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

Іронія багатьох “якщо-що” у тому що вони, вибачте, нахєр нікому крім інженерів не потрібні. Дуже часто користувачам потрібно щось просте. Не піздато технологічне, не повний оффлайн та мільйон налаштування, не супер надійне на 4 дев’ятки. Додам трошки – за умов вартості на розробку ідеї, втрати часу на вихід до проду, ускладнень в тестуванні, архітектурних конфліктів тощо. Нажаль замовник буде disappointed and angry.

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

  • Ситуація залежить від структури цільових компонент Enterprise архітектури
  • Це частина визначених проблем та можливостей бізнесу
  • Чи зацікавлений будь-який stakeholder у ситуації
  • Чи є ситуація “правильною” з боку бізнес правил замовника
  • Чи визначили ми вірогідність ситуації, вартість проблеми та витрат на вирішення ситуації. Також необхідно знати ефект

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

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

Залишити відповідь