Що робити, якщо начальник завжди відкладає основні рішення щодо вимог та загального дизайну?

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

Щоб питання було максимально загальним: що ви робите, якщо ваш начальник не любить приймати рішення?

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

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

Побудувати прототипи

Просто почніть малювати екрани, які спочатку нічого не роблять (мабуть, у вас цього достатньо?)

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

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

З вашого повідомлення я зібрав декілька питань: 0 - Ви не керуєте проектом, і зібрати вимоги кінцевих споживачів - це не ваша робота. 1-Бос не знає точних вимог 2-Бос не розмовляє з кінцевими споживачами про вимоги 3-Бос кидає термінологію, він насправді не розуміє спритного 4-Ви розробляєте рішення, яке стає повторним написано кілька разів, і вам це не приємно

Що стосується 1,2 та 3, то з цим мало що можна зробити, якщо ви не людина старшого віку. Однак можна зробити наступне:

A - Попросіть його поділитися з вами планом проекту. Він може мати його або створить одне із показаних завдань та термінів. Одне з них має стосуватися аналізу та збору вимог. Якщо не запропонуйте.

В - Підготуйте деякі посилання на важливість вимог до успіху програмного проекту

C - Підготуйте йому 1 сторінку того, що Agile є, а що ні.

D - Підготуйте йому список типових входів на етапі проектування та переконайте його у цінності кожного.

E - Запропонуйте до колективу ділового аналітика та / або моделера даних. Такі ролі повинні мати місце з кінцевим користувачем, і ви отримаєте необхідну інформацію або хоча б хорошу її частину.

F - Подивіться, як інші розробники готувались з цим хлопцем.

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

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

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

Це не добре!

Удачі.

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

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

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

У нас є приказка навколо $ WORK (внутрішніх веб-додатків) для наших клієнтів: "Я дам вам щось, щоб ви могли сказати мені, що ви хочете". Будьте готові викинути першу тягу, але ви можете здивуватися, як рідко вам доводиться це робити.

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

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

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

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

І звичайно переконайтесь, що він думає, що це була вся його / її ідея. (особливо коли все йде не так!)

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

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

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

Приймайте рішення самостійно і починайте кодувати. Звичайно, розвиток гнучким способом допоможе (прочитайте "Швидкі шаблони, принципи та практики Роберта Мартіна, якщо ви цього ще не зробили)", але вся гнучкість у світі не допоможе, якщо жодного рішення не буде прийнято. Ви можете виявити, що вам доведеться просто розвивати те, що ви думаєтепотрібна, а потім змінюючи її відповідно до необхідності. Часто клієнти / начальники не знають, чого хочуть, поки не бачать, або поки не бачать те, чого не хочуть. Це, ймовірно, виведе вас за межі того, щоб бути розробником, але це життя. Я часто виявляю, що я та мої колеги ефективно приймають ділові рішення. Іноді це не викликає сумнівів, і рішення, які я прийняв, починають керувати бізнесом, тільки тому, що ніхто більше не приймає рішення. Обов’язково перерахуйте ВСІ з ваших припущень та рішень (без винятку) та подайте їх своєму начальнику.