Встановлення реалістичних очікувань строків


15

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

Зазвичай взаємодія йде за такою схемою. Клієнт пропонує функцію, яку він хоче додати, Feature X. Feature X буде добре виглядати в релізі додатка на наступний тиждень, який займає близько 6 робочих днів. На даний момент запит на функцію повинен пройти затвердження, і часто існують інші залежності, з якими потрібно вирішити. Врешті-решт, через N днів, запит на функцію проникає до моєї команди. Навіть якщо початковий мертвий рядок (який встановив менеджер, який не розробник) був досяжний, він більше не є. Моя команда звинувачується, відчуває себе розгубленою, і там загальна атмосфера поразки , я відчуваю себе розгубленим і переможеним.

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

Ви були в подібних ситуаціях? Що для вас не працює?


13
Залишати. Ви не можете перемогти. Ви керівництво не захищає вас, тому вони не піклуються про вас. Залишати.
Крістофер Махан

4
"Це дуже схоже на те, що я виправдовуюсь."? Чому? Факти - факти. Що ви "вибачаєте"?
S.Lott

Ми не працюємо в blackbox. Якщо команда нефункціональна, то лише стільки безсилий розробник може зробити.
P.Brian.Mackey

2
@EightyEight: Техніка "виходу з лінії" нічого не пояснює. Це або ти, або команда (а може, і те й інше). Але вибірка не допомагає нікому зрозуміти, у чому полягає ваше питання . Добре видаляти речі, які не відповідають дійсності чи не стосуються.
S.Lott

Відповіді:


13

Вам дійсно потрібно поговорити з вашим начальником про це і встановити деякі основні правила:

  • Кінцевий термін - це не граничний термін, якщо ви його не зобов’язані
  • Оцінка не є оцінкою, якщо ви не даєте її, і тоді це "оцінка" не важкий термін.

У чистому кодері Роберта Мартіна є дійсно гарна глава про те, як повідомити цей матеріал своєму начальнику. Це не ваша вина, якщо торгова команда бере на себе неможливі зобов’язання.

Коли ви отримуєте нову функцію, ВИ ВИ оцінюєте її та використовуєте PERT, щоб мати розподіл ймовірностей. "Я повинен це зробити за 4 дні, але це може зайняти цілих 8". Стояти на своєму. НІКОЛИ не домовляйтеся про оцінку з продавцем, ви в кінцевому підсумку покладетеся на неможливе.

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


1
+1 - розробники / люди, які знають, що насправді пов’язано, не беруть участі в оцінках криків божевільних божевільних: /
elwyn

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

"Дедлайн - це не граничний термін, якщо ви не зобов'язані його виконати." Мені так сподобалось, що я просто твітнув. ;)
Боб Горн

10

Ви були в подібних ситуаціях? Що для вас не працює?

Переважно те, що працює - це говорить правду владі.

Зберіть факти. Представіть факти. Залиште замовника вчитися (чи не вчитися) у власному темпі.

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

Чому ваша команда усвідомлює провину? Якщо замовник обходить вас і спілкується безпосередньо з командою, ви стаєте неефективними, і вам потрібно з’ясувати, чому.

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

Замовник повинен --- врешті-решт --- вирости, щоб зрозуміти процес. Щоб зламати шкідливі звички, потрібно багато разів повторювати. Дуже багато.


+1 "говорити правду владі". Ви можете уточнити, будь ласка? Мені подобається заява "невігласа" провини ". Я хотів би знайти компанію, яка зупинила б усі безглузді вказівки пальцем"
P.Brian.Mackey

"Зберіть факти. Представіть факти". Я думав, що це було зрозуміло. Що ще можна сказати?
S.Lott

Я думаю, я зараз це зрозумію. Я просто ніколи раніше не чув цього терміна.
P.Brian.Mackey

3
"зупинив усі безглузді вказівки пальцем". Його не можна зупинити. Але роль керівника команди - захищати команду від найгіршого.
S.Lott

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

5

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

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

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

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

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


3

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

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


Ніколи не приймайте термін "... до понеділка". Це просто означає, що чорти витратять кодування на вихідні, якщо лайно потрапить у фанат. Використовуйте п'ятницю як крайній термін або, ще краще, середу.
sbi

2

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

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


2

Зафіксуйте інформаційний потік.

  • Якщо ви повинні спілкуватися з клієнтом, змусити всі учасник проекту (включаючи клієнт) безпосередньо взаємодіяти з вами, завжди .

На жаль, владу в основному беруть самі, а не надають вам інші.


1
Так, це станеться. Хоча, якби ви це зробили, ви, мабуть, звільнилися б і отримаєте купу поваги з боку людей, з якими працюєте, та від деяких клієнтів (які, ймовірно, хворіють і втомилися від управління вашою компанією).
Крістофер Махан

2

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

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

Клієнт пропонує функцію, яку він хоче додати, Feature X. Feature X буде добре виглядати в релізі додатка на наступний тиждень, який займає близько 6 робочих днів. На даний момент запит на функцію повинен пройти затвердження, і часто існують інші залежності, з якими потрібно вирішити. Врешті-решт, через N днів, запит на функцію проникає до моєї команди. Навіть якщо початковий мертвий рядок (який встановив менеджер, який не розробник) був досяжний, він більше не є.

Ця система планування планується, щонайменше, дивною.

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

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

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

На жаль, я не дуже багато можу зробити, тому що я тут не в силі.

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

Це дуже схоже на те, що я виправдовуюсь.

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


Для вирішення деяких інших відповідей.

На жаль, владу в основному беруть самі, а не надають вам інші.

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

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

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

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


2

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

Ви можете представити це так, як можете зробити це через X кількість днів, коли ваша команда почне працювати над ним. Може, це була плутанина? Це чесна помилка, якщо вона не трапляється знову і знову. Тоді це просто нехтування.

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


2

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

Якщо все інше не вдається, залиште.


1

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

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


1

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

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

Тепер поговоріть із вашим начальником наступним чином:

У нас було X доступних годин людини між датою початку проекту Y та кінцевим терміном Z.
Для завершення проекту потрібні X + C чоловічих годин
Подібні поворотні вимоги були і в інших проектах.
Нам знадобляться додаткові програмісти Q для досягнення потенціалу, необхідного для задоволення очікувань.
... звичайно, якщо бюджети є обмеженими, можливо, ми могли б співпрацювати з менеджерами проектів, щоб вкласти більше часу на їхні оцінки, щоб ми могли пообіцяти і переоцінити (обов'язково використовуйте банальне управління)

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.