Що робити, коли клієнт має нереалістичні очікування? [зачинено]

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

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

Оскільки клієнт не є програмною компанією, і через різні політики, мені знадобилося 20-25 днів, щоб дати мені права на мою машину встановлювати такі речі, як Eclipse, Tomcat тощо. Навіть після затримки з налаштуванням середовища, вони все ще очікували, що я завершу проект за той самий два місяці.

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

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

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

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

Я вже працюю 11-12 годин щодня і подорожую 3-4 години, і тепер вони очікують, що я також прийду суботами.

Я маю тут зробити все: взяти вимоги, дизайн, код та тест.

Підкажіть, будь ласка, що робити в такому випадку?

_{Додаткові деталі: У нас був список результатів, але потім вони додали ще кілька речей, кажучи, що вони також важливі. Вони також змінили кілька результатів. Вони навіть не мають свого UAT-сервера, вони перевіряють на моїй розроблювальній машині через її IP-адресу.}

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

Ваш менеджер, оскільки вони планують зустрітися з ним, повинен отримати від замовника певний набір вимог - проект повинен виконувати A, B, C, D і E. І після цього він завершиться. Підпис замовника повинен бути на тому документі, який погоджується із цим списком. Ви повинні були мати це з самого початку.

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

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

Ви проводите зустріч, де потрібні додаткові функції? Запишіть його згодом, позначте «+ X днів до поточного розкладу» на кожному пункті та надішліть його всім учасникам. Якщо ви використовуєте лише внутрішню поштову систему клієнта, додатково роздруковуйте її, включаючи:, cc: та bcc: список одержувачів та ретельно архівуйте їх. Крім того, як сказав GrandmasterB, замовник повинен підписати такі зміни до початкових вимог.

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

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

З того, що ви описуєте, видно, що ви берете участь у класичному проекті Маршу смерті :

В управлінні проектами , марш смерті є однією з декількох видів патологічних проектів з участю dysphemistic, темно-гумор аналогія з реальними маршами смерті, таких як тяжко перевантажена робота та (найчастіше та особливо) тяжко перевантажена роботою з необґрунтованих причин для проекту, який, очевидно, є високим ризиком поганого результату (тобто, провал проекту та, можливо, загроза пошкодження репутації особистої та групової репутації) . Таким чином, назва "марш смерті" може бути застосована до проекту, який в кінцевому рахунку є успішним, але передбачає розтягнення вдома нестабільної непосильної роботи, або (можливо, частіше) до проекту, який може бачити будь-який інтелігентний, обізнаний член, провалений (або є з дуже високим ризиком невдачі), але все-таки члени все-таки змушені діяти над начальством ...

Феномен добре відомий, і є багато літератури про те, як діяти, зокрема, зокрема, семінарійну книгу Едварда Вайдона « Смерть Марш: Повний посібник розробника програмного забезпечення для виживання проекту« Місія неможлива » .

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

Гуляючи у взутті, перше, що я вважаю, - це передавання посиланням на вищеназвану статтю моєму менеджеру.

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

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

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

Найкраще скоротити свої втрати і знайти інший концерт. Але подумайте над своїм досвідом і скористайтеся порадами інших відповідей на цю тему.

Це серйозно issue in project management . Схоже, що вам Project Managerслід працювати над доступними списками та визначати їх пріоритетність перед клієнтом.

Самий важливий , ваш PM should discussі згоден з Клієнтом час кадру (включаючи проектування і аналіз проблеми / рішення) в ваших оцінках.

Наявність clear estimation of your work loadта доставлення предметів проекту позбавить вас від стресу, а також додасть душевного спокою та впевненості у вашій роботі.

Спробуйте використовувати підхід Agile , доставляючи ваші предмети в спринті (2-3 тижні) та здійснюючи UAT (тест прийняття користувача) з клієнтом. Пам’ятайте, завжди займайтеся плануванням спринту перед початком спринту.

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

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

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

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

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

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

Далі, не дозволяйте собі зловживати робочими 11-годинними днями та вихідними. Це нормально в коротких спуртах (менше 1 тижня кожні півроку або близько того), але в довгостроковій перспективі це просто не прийнятно. Втомилися люди кодують повільніше, і вони роблять більше помилок. Ви можете зробити більше, працюючи з більш високою якістю, регулярно працюючи на 8 годин, ніж регулярно 11 годин. і вихідні дні.

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

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

З Вікі :

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