3 головних питання в ремеслі програміста

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

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

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

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

Хто ми?

Основне питання для кожної команди. Без розуміння своєї команди дуже складно зіставити очікування і реальність від її дій.

Ви можете запитати себе:

Скільки нас в команді?
Наскільки високий рівень підготовки?
Які наші мотиви?

Це питання допомагає зрозуміти свою команду, її можливості та обмеження. Якщо ви група JS-девов, то вам навряд чи варто братися за embedded-розробку. Так само як не має великого сенсу відправляти людину з 15 роками досвіду З++ розробки на розробку сайту для продажу котячого корму.

Якщо ви в команді єдиний сеньйор, а навколо вас крутиться зграйка незміцнілих морально джунов, то варто дотримуватися консервативних, добре відомих технік і фреймворків. А не братися за самий новий стек технологій і заганяти свою команду на пустельну сторінку в Stack Overflow з питанням без відповіді: «A як же ця нова мегаштука повинна парсити JSON?».

Де ми?

Де ми — це нагальне питання. Тому що він відноситься до вкрай цінного ресурсу — часу. Можливо, має сенс перефразувати це питання «Коли ми?» . Але боюся, якщо ви задасте вашому босові таке питання, то надовго на цій роботі ви не затримаєтеся :)

Необхідно зрозуміти тип проекту/продукту, над яким ви працюєте. І на якому етапі розробки він знаходиться. А також розуміти стан компанії, в якій ви працюєте.

Спробуйте запитати себе:

Ми робимо продукт?
Ми працюємо як аутсорс/аутстаф?
Ми позиціонуємо себе як IT-consulting?
Ми велика компанія?
Ми маленька компанія?
Ми на початку/середина/кінець великої/середньої/маленького проекту?
Ми на етапі підтримки продукту?

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

Куди ми йдемо?

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

В основному вас повинні цікавити найближчі майлстоуны та дати релізів. А також функціонал, який необхідно надати.

Наприклад:

Чи очікується у найближчий місяць major release нової пачки фіч?
Ми повинні якомога швидше випустити MVP?
Коли найближчим демо для стейкхолдерів?
Чи повинні ми за короткий час вийти в лайв і чекати пачки багів для екстреного фікса від реальних клієнтів?

Якщо все, що вас чекає, це внутрішнє демо для команди, то не варто витрачати надто багато часу на CI/CD та документацію. Але якщо ви робите major release вашої бібліотеки, який поламає половину старих API, — слід поставитися до документування зміни як можна більш серйозно.

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

На жаль, інколи ніхто, абсолютно ніхто не може дати відповіді на це питання. В таких випадках я зазвичай переформулюю питання «Як зрозуміти, куди ми йдемо?» . Пишу пару листів людям, які могли б хоч щось про це знати. А потім вирушаю запускаю static analyzer і починаю правити код проекту :)

Профіт

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

Наприклад, розглянемо таку ситуацію:

Ви маленька команда у великій компанії з завданням мейнтейнить стару систему з дуже великою користувача активністю.

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

З іншого боку:

Ви велика команда у великій компанії з завданням мейнтейнить стару систему з дуже великою користувача активністю.

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

Ще один приклад:

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

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

Порівняйте з такою ситуацією:

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

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

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

Ітеративності

Процес розробки ПЗ має ітеративний характер, іноді. Відповідно, слід ставити собі 3 головних питання перед кожною ітерацією.

Відповідальність і лідерство

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

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

Висновок

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

Опубліковано: 16/08/17 @ 10:20
Розділ Різне

SEO Блог