Застосування

Якщо постояти будь-де досить довго, за тобою вишикується черга.

«Закони Мерфі та пов'язані з ними висновки»

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

Правил, які дозволяють відволікатися на рутину лише в разі відхилень.

У суперечці народжується істина... але іноді помирає здоровий глузд.

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

Мінімальний життєздатний продукт (minimum viable product, MVP) — продукт із мінімальними, але достатніми для задоволення потреб перших споживачів функціями

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

Але MVP — дуже корисна річ у розробці загалом.

Тут я поділюся досвідом застосування MVP у сервісних підрозділах розробки компаній поза ІТ-галуззю.

Отже, у нас є розробник, а можливо, і не один.

Ви їхній керівник.

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

І у вас є замовники. Внутрішні, але від цього не менш важливі й улюблені :-)

І одного разу в когось у компанії виникає думка: а розробімо продукт X.

Отже, бажання замовника є, він має повноваження й готовий працювати. 

Поїхали.

Працювати з людьми — найскладніше. Принаймні для мене.

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

Заохочувати ініціативність і самостійність, але не дозволяти їм перетворюватися на самоуправство та нехлюйство.

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

Нижче — кілька моїх правил і принципів, напрацьованих досвідом.

Краще один раз побачити, ніж сто разів почути.

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

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

Ага, так, звісно — три ствердні слова поспіль, а зміст протилежний... 

Це був марно витрачений час. Натомість ми отримали досвід, який, як відомо, безцінний.

Отже, коли відеоінструкція — зло:

Правильне технічне завдання, або ТЗ, — яке воно?

Грубо кажучи, воно має відповідати на два запитання:

1. ЩО ми хочемо отримати?

2. ЯК це має бути зроблено?

Тобто складатися з двох великих частин. 

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

Ми називали їх побажаннями.