Чи прийнятно проекти перевищувати бюджет?

11

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

Наші продавці часто задають нам щось подібне до наступної серії питань:

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

Як ми можемо дати пропозицію без будь-якої інформації? ( Ні, я не можу просити більше інформації! )

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

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

Якщо ви працюєте в веб-розробці / дизайні / подібній компанії:

3. Як працює ваша система оплачуваної години?

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

EDIT: Гаразд я розробник цієї фірми, а не дизайнер :)

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

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

project budget

— Брендон Вамбольдт
джерело

4

Поширене неправильне уявлення: "Я не можу просити більше інформації!". Зазвичай тобі кажуть, що не можеш, але якщо ти достатньо підеш на це, то в кінцевому підсумку зможеш.

— Вінко Врсалович

2

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

— HLGEM

1

Переверніть його. Попросіть своїх продавців точної відповіді на те, "скільки часу знадобиться для закриття продажу?" :)

— CraigTP

Повинно бути приємно працювати лише 35 годин.

— Риг

@HLGEM Ось чому ви використовуєте оцінки "Скотті". Як і Скотті з "Стар Трек", ви завжди завищуєте, скільки часу щось займе / скільки це коштуватиме, щоб клієнт міг спробувати і поговорити про зменшення бюджету на час / гроші. Якщо ви скажете їм, що ви думаєте, що насправді знадобиться, а вони вимагають менше, ви застрягли.

— GordonM

4

Наші продавці часто задають нам щось подібне до наступної серії питань:

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

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

Як ми можемо дати пропозицію без будь-якої інформації? (Ні, я не можу просити більше інформації!)

Коротка відповідь? Ти не можеш, не намагайся.

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

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

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

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

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

— Джош К
джерело

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

— Брендон Вамбольдт,

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

— Josh K

4

Робіть те, що робить Скотті: придумайте розумну оцінку та подвоюйте її.

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

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

Удачі.

— Патч
джерело

1

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

— Крамій,

1

Подвійне - це занадто малий запас. Я завжди йду за правилом множення на пі.

— Bjarke Freund-Hansen

1

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

— Брендон Вамбольдт

@ Rogue Coder: Зазвичай найкраще давати точні оцінки продажів (і під точними, я маю на увазі подвоєні, або навіть pi'd або вчетверо) оцінки. Якщо продажі тиснуть на те, щоб ви брехали про те, скільки часу буде потрібно, щоб вони могли запакувати більше роботи, вони створюють проблеми для себе. Але я думаю, що ви робите припущення щодо того, що продавець хоче почути - спробуйте вищі оцінки; якщо ви почнете доставляти речі вчасно та з бюджету, ви можете опинитися з дуже щасливим начальником та щасливими продавцями.

— Патч

@ Rogue Coder: Якщо це займе x кількість часу, то це триватиме тривалий час, навіть якщо продажі намагаються промовити це. Якщо ви почнете втрачати клієнтів, зменшіть ставку (а точніше, запропонуйте їм "знижку" на вашу ставку).

— Кріс Бакетт

2

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

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

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

Можна спробувати взяти Закон Хофстадтера, але це ніколи не вийде .

— Адам Харте
джерело

1

Ми робимо це певною мірою. Я створюю список, який говорить: CMS встановлюється 1 година, модуль подій 4 години, бла-бла-6 годин, конверсія контенту 10 годин. Дві проблеми з цим полягають у тому, що вони є кошторисом, і хлопець з продажу перетворює їх на абсолютно різні речі при відправці контракту. Це спричиняє проблему, коли клієнти кілька разів видалять частину проекту, оскільки хлопець з продажу вказав "Основну функціональність IV" як "Марна функція XII". Клієнт цього не хоче, але це насправді потрібна робота, і тому я втрачаю необхідний бюджет.

— Брендон Вамбольдт,

2

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

— Вінко Врсалович

1

Це насправді лише відповідь на першу частину вашого трипартійного партеру, але це велике питання.

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

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

Я кажу їм, що їх перший рахунок-фактура, що підлягає сплаті, становить 25% від кошторису. За цією ціною ми виконаємо повне зусилля зі збору вимог і запишемо повні, детальні технічні характеристики. Залежно від розміру проекту, це може бути кілька тижнів роботи. Наприкінці цього у нас буде повний набір документації, І ми будемо знати, як ми зробили цю оцінку. Якщо в цей момент нам доведеться уточнити ціну (а вона може піти вгору АБО вниз), ми зробимо це і повідомимо клієнту.

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

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

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

— Ден Рей
джерело

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

— Роберт Харві

0

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

— тіа
джерело

0

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

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

З часом і досвідом вам стає краще .

Чи є в компанії ще хто ми дизайнер? Якщо так, я настійно пропоную вам зайнятися Плануванням покеру . Це дуже потужна методика колективної оцінки.

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

Це допоможе вам отримати більш точні оцінки, використовуючи знання та досвід більшої кількості людей, а відповідальність за оцінку буде поширюватися на команду замість однієї єдиної людини. Продажі будуть задоволені, оскільки вони отримають більш точні оцінки. І простіше сказати "ми не можемо оцінити", коли тобі 4 або 5, ніж коли ти є лише собою.