- Фу! До чего же дичь пошла бестолковая — я полдня за ней бегал, чтобы сфотографировать!
- Это ещё мало, теперь ты ещё за ним полдня бегать будешь.
- Это почему же?
- А чтоб фотографию отдать.Канікули в Простоквашині
Усе наведене нижче я писав про внутрішню розробку й підтримку.
Коли завдань багато, а ресурсів ІТ на всіх не вистачає.
Я кілька разів сам наступав на ці граблі. Чув багато історій від колег.
Про схожі проблеми — матеріали «Нікому не потрібний подвиг» і «Супераналітик-оптимізатор».
Тепер суть:
За розробку беруться лише тоді, коли є замовник із чітко визначеною потребою.
Будь-який рядок коду пишуть лише тоді, коли замовник готовий витрачати час і сили на:
- постановку завдання: розмову з аналітиками для складання ТЗ;
- упровадження: роботу з опором, підвищене навантаження під час запровадження.
Лише коли виконано ці умови, можна витрачати час програмістів на розробку, а аналітиків — на складання ТЗ.
Інакше ви дуже ризикуєте уподібнитися Шарикові й бігати за дичиною користувачами і під час складання ТЗ, і, що найнеприємніше, під час упровадження.
Нижче — реальні випадки з граблями, і не лише моїми. Усі імена змінено, всі збіги випадкові.
1. Застаю на робочому місці засмученого розробника.
Суть: Він вирішив полегшити життя користувачам. Зробив автоматичне заповнення деяких полів, залежні списки тощо. Витратив власний час. А коли прийшов здавати роботу, виявилося, що це нікому не потрібно: порядок заповнення полів не такий, як на формі — зліва направо, згори вниз, — а свій. Залежність не спрацьовує, а лише заважає.
Це радше випадок «Нікому не потрібного подвигу».
Висновок: немає замовника — немає розробки.
2. Знаходжу в системі відстеження завдань виконане завдання, яку замовник понад місяць не приймає й не тестує. Розробник уже не пам'ятає деталей ТЗ. І виправлення будь-яких зауважень для нього — величезна втрата часу, щоб знову зануритися в давно забуте завдання.
Суть: ТЗ формулював не замовник, а внутрішній аналітик про таке написано тут. Тобто замовникові це не потрібно. Він просто, щоб від нього відчепилися, назвав певну проблему або погодився з припущенням аналітика, що це проблема, й далі займався своїми справами. У функціонального фахівця справ вистачає. А аналітик вирішив, що ось вона, його знахідка, шанс зробити світ кращим. І постарався: у ТЗ і додаткові зручності, і прикраси, і рожеві кнопочки, і всілякі перевірки.
Висновок: той, хто складає ТЗ, — не обов'язково замовник. Внутрішній аналітик часто лише посередник, і його цілі інші. Хоча винятки можливі, й про це важливо пам'ятати.
3. Керівник підрозділу звертається до розробників із проханням залучити аналітика до великого проєкту автоматизації. У загальних рисах описує проблему: стара програма для зв'язку з державними органами, яка часто зависає, не обмінюється даними з основною ERP-системою. Потрібно або знайти нову, або самостійно створити щось подібне як модуль ERP. За описом програма — невелика база даних, відтворити яку буде не надто складно. Усе логічно. Потрібно попрацювати. Проєкт у такому загальному вигляді погоджують на всіх рівнях ухвалення рішень. За день засмучений аналітик приходить до мене й просить зняти з нього проєкт.
З'ясовую: керівник не поговорив зі своїми працівниками, які нібито страждають від неавтоматизованої роботи. І аналітик, який прийшов поліпшувати їхнє життя, довго вислуховував, що в них і так усе добре, що програма швидка й зручна, бо має зв'язок із базою даних того самого державного органу. І жодними даними з ERP ніхто не обмінюється.
Висновок: Царь-то не настоящий. У замовника насправді немає проблеми, але є бажання не залишатися осторонь і долучитися до автоматизації підприємства — бути в тренді, так би мовити.
На практиці важко уявити, щоб керівник аж настільки не розумів роботи підлеглих. Але потрібно розуміти, що так буває. Можливо, не настільки відірвано від реальності, як показано вище, проте наслідки від цього не менш прикрі.
Загальний висновок: з'ясовуйте, хто справжній замовник, виявляйте його реальні проблеми та зацікавленість.
Зауваження.
Іноді потреба в автоматизації є не в функціональних фахівців, яких усе влаштовує, а в першої особи. Це нічого не змінює: однаково потрібно знайти тих, кому це потрібно, і взаємодіяти з ними.
І ще дуже важливо: ви маєте бути спроможні підтримувати створене.
Не буває написаного коду, який не потрібно підтримувати.
Є користувачі — отже, є запитання; змінюються процеси — отже, потрібні доопрацювання системи.
Винятки лише підтверджують правила. Класна фраза, правда?
Тому:
1. Потрібен справжній замовник.
2. Потрібна можливість потім супроводжувати створене. Докладніше про це тут.