Як укласти мир із термінами розробки програмного забезпечення

ТЕРМІН ...

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

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

Цікаво, звідки я це знаю?

Я знаю, бо я відчував те саме. Але зараз страх залишився в минулому. Я уклав мир із встановленими термінами. Я обійняв їх.

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

Гаразд, але як ти можеш це зробити?

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

Працюйте в спокійній обстановці

Не поспішайте. Нічого не змушуйте.

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

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

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

Наші оцінки відмовні

Користувачі Windows запам'ятають це діалогове вікно. Оцінка у діалоговому вікні точно така ж, як і наша оцінка, чи не так?

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

Однак загалом, коли ми здогадуємось, ми ігноруємо деякі важливі фактори, які можуть вплинути на наші припущення. Чому? Тому що ми занадто оптимістичні.

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

Розділіть великі речі на дрібніші . Чим він менший, тим легше його оцінити . Це збільшить ваші шанси на отримання більш точних оцінок.

Досить добре - це добре

"Досконале - це ворог добра". - Вольтер

Люди люблять великі виклики. Нам найкраще знайти складне рішення простої задачі. Але ось факт:

Кожна проблема має своє просте рішення, яке ви, мабуть, ігноруєте.

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

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

Не будь занадто оптимістичним. Будь реалістичним.

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

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

Пам’ятайте, що кожна команда думає про свою сторону.

Розмежуйте між "ти повинен зробити", "ти міг би зробити" і "ти хочеш зробити"

Порозуміння тут є ключовим. Які основні вимоги до випуску вашого продукту? Зазвичай команда продуктів важко диференціює їх.

Коли у вас є зустріч, один із членів команди скаже: “ми могли б це здійснити, це принесе нам стільки користі”, а інший - “Ми повинні це звільнити”. Вони дивляться з власної точки зору. Гаразд, ми можемо реалізувати це, і це може принести нам певну цінність, але важливим питанням є те, що «чи нам це потрібно зараз? У першій версії? "

Відповідь - НІ в більшості випадків.

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

Скажіть "ні" за замовчуванням

Є один важливий факт, про який ми зазвичай забуваємо, коли кажемо чомусь “так”. Ми говоримо «ні» тим, що нам уже потрібно виконати.

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

“Давайте додамо більше завдань до проекту після того, як ми встановимо термін. (Ваш проект з часом повинен ставати меншим, а не більшим.) ” НІ .

“Ми зосередилися на тому, що має значення, добре. Але як щодо деталей? Давайте розглянемо, які у нас є деталі, які можуть створити проблеми в майбутньому ». NO . Ігноруйте кожну деталь першої версії. Не намагайтеся передбачати майбутнє.

Тут не проблема знайти більше часу для речей. Проблема в тому, що потрібно зробити занадто багато речей. Розмежуйте між “ обов’язковими ” та “ приємними ”.

Єдиний спосіб зробити більше - це зробити менше.

Ніколи не змінюйте термін

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

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

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

Майте на увазі, що завжди будуть проблеми

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

Мій досвід показав мені, що при розробці програмного забезпечення деякі речі завжди йдуть не так. Моя порада вам:

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

Не додайте більше людей до проекту

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

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

За словами Брукса у Вікіпедії, існує додаткова людина, яка, додавшись до проекту, змушує зайняти більше, а не менше часу. То чому це працює так?

  • Потрібен певний час, щоб люди, додані до проекту, стали продуктивними. Спочатку вам доведеться їх виховувати. Ви вже обмежили людські ресурси, і вам доведеться виділити ці ресурси для навчання нового члена. Оскільки вони є новими, вони запровадять нові помилки, які віддаляють проект від завершення.
  • Накладні витрати на спілкування зростають із збільшенням кількості людей.
  • Додавання більшої кількості людей до надзвичайно ділимого завдання, наприклад, прибирання номерів у готелі, зменшує загальну тривалість завдання. Однак інші завдання, включаючи багато спеціальностей у програмних проектах, менш поділяються. Ще один чудовий приклад цього Брукса: хоча одній жінці потрібно дев'ять місяців, щоб завести одну дитину, "дев'ять жінок не можуть народити дитину за один місяць".

Ще один доказ Річарда Далтона про те, щоб зрозуміти, чому додавати більше людей неправильно, це:

“Команди незмінні. Щоразу, коли хтось залишає чи приєднується, у вас з’являється нова команда, а не змінена команда ”. - Річард Далтон

Не зволікайте

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

Було завдання, на яке ми сильно витратили час. Було три способи реалізувати це завдання, але якось ми застрягли. Ми не могли вибрати, оскільки розробники намагалися передбачити майбутнє. Вони починали кожне речення з "Що якщо".

Ви не можете передбачити, що принесе вам майбутнє. Не надто готуйтеся до невідомого.

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

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

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

Спілкуйтеся: подивіться, де вузьке місце?

Ви все запланували. Ви визначили, на чому слід зосередитись і що робити. Ви точно знаєте, скільки часу це займе (можливо, ви помилитеся). Отже, термін встановлений. Чи достатньо?

НЕМАЄ.

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

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

Бажаю вам удачі у дотриманні всіх ваших термінів :)

Дякуємо за читання.

Спочатку опубліковано на //huseyinpolatyuruk.com.