Как конкурировать в недостаточном spec'd проекте избежать [закрытого] похоронного марша команды
Пара несколько месяцев назад я waasn't способный установить Ubuntu 11.10 в MacBook Pro 5.1 (в конце 2008, в начале 2009), и я должен был использовать образ дисков 10.10 и обновления оттуда весь wy теперь к 12,04. По-видимому, была проблема с загружающейся системой, которая заставила ее отказать с более новыми версиями. Я использовал EFI для выбора, который ОС загрузить в, и всегда настольная версия Ubuntu (я думаю 32-разрядный). Конечно, я не знал там, где стандартные рисунки рабочего стола корректировались к работе правильно над системами Mac (может быть, это - новая вещь?)
Поэтому, если Вы следуете всем инструкциям и это не загружается, я предложу попробовать более старой версией ;)
6 ответов
Добро пожаловать в мир услуг по разработке с фиксированной ценой: -)
Методы для победы в этом проекте и в то же время избежать ситуации марша смерти:
- Не перебить проект. Сделайте ставку за то, что, по вашему мнению, займет проект, и добавьте некоторый процент за то, что может пойти не так.
- Если вам не хватает 75% деталей, скорее всего, проект будет значительно отличаться от того, что вы ожидаете в настоящее время. Задокументируйте некоторые разумные предположения о деталях в рамках определенной работы. Когда проект действительно начинается, а детали не соответствуют предположению, у вас есть возможность договориться о стоимости изменений. В то время вы также можете лучше узнать, сколько у вас больше / меньше, и попытаться компенсировать эту цитату.
- Ваша цель в SOW (техническом задании) должна заключаться в том, чтобы определить достаточно деталей, чтобы это дало вам возможность пересмотреть стоимость изменений, когда вы больше узнаете о проекте. Напишите как можно больше положительных моментов. Обратите внимание: маловероятно, что люди, которые действительно понимают проект, прочитают или поймут SOW ... Я основываю это на том, что вам дается несколько деталей для цитирования. Это означает, что это не консультативная продажа, и ни одна из сторон на самом деле не сосредоточена на построении «правильного» решения.
- Если вы можете получить контракт как T&M (время и материалы), отлично. Я сомневаюсь, что вы это получите или не сможете получить без каких-либо ограничений, которые по сути сводят на нет цель T&M. Ваши потенциальные клиенты смотрят на это, поскольку они принимают на себя все риски, связанные с вашими способностями.
- Надеюсь, что вы не согласны ». t первым в вашей компании это сделает. Узнайте исторически сложившиеся проекты и типичные показатели результатов. Многие группы разработчиков программного обеспечения взимают почасовую оплату, которая значительно превышает стоимость ... но их расценки, как правило, ниже, а не фактические часы. Клиенты часто будут больше спорить о часах / днях, чем о фактической цене. Предприятия, как правило, привыкли платить высокие почасовые ставки.
- Определите ожидаемую маржу вашего отдела (прибыль, которую вы должны получить от работы). Это может помочь вам понять, с какой степенью «марша смерти» вы можете столкнуться, когда ваш проект не сработает.
- В SOW укажите уровень детализации, который потребуется в спецификации, прежде чем вы начнете работу. В то время как Agile и другие процессы, ориентированные на клиента, используют подход, ориентированный на поиск лучшего решения, это не так. t разработан, чтобы держать расходы под контролем в условиях фиксированных ставок. Вам нужно будет применить водопадный подход к требованиям, а затем строить гибко, чтобы вы могли приспосабливаться по ходу дела. Спецификация, как и SOW, дает вам возможность выставить счет за изменения. Хотя заказчику это не понравится, это возложит бремя и риски, связанные с требованиями, на них, а не на вашу команду.
Обратите внимание: чтобы добиться успеха в этих переговорах, вам потребуется поддерживающая команда менеджеров, продаж и управления проектами. Если у вас этого нет, вы обязательно будете в «марше смерти». Даже если вы откажетесь от качества, процесса, тестирования и прочего, вы обнаружите, что для проекта никогда не хватает времени.
Вам нужно будет применить водопадный подход к требованиям, а затем строить гибко, чтобы вы могли приспосабливаться по ходу дела. Спецификация, как и SOW, дает вам возможность выставить счет за изменения. Хотя заказчику это не понравится, это возложит бремя и риски, связанные с требованиями, на них, а не на вашу команду.Обратите внимание: чтобы добиться успеха в этих переговорах, вам потребуется поддерживающая команда менеджеров, продаж и управления проектами. Если у вас этого нет, вы обязательно будете в «марше смерти». Даже если вы откажетесь от качества, процесса, тестирования и прочего, вы обнаружите, что для проекта никогда не хватает времени.
Вам нужно будет применить водопадный подход к требованиям, а затем строить гибко, чтобы вы могли приспосабливаться по ходу дела. Спецификация, как и SOW, дает вам возможность выставить счет за изменения. Хотя заказчику это не понравится, это возложит бремя и риски, связанные с требованиями, на них, а не на вашу команду.Обратите внимание: чтобы добиться успеха в этих переговорах, вам потребуется поддерживающая команда менеджеров, продаж и управления проектами. Если у вас этого нет, вы обязательно будете в «марше смерти». Даже если вы откажетесь от качества, процесса, тестирования и прочего, вы обнаружите, что для проекта никогда не хватает времени.
Таким образом, это возлагает бремя и риски, связанные с требованиями, на них, а не на вашу команду.Обратите внимание: чтобы добиться успеха в этих переговорах, вам потребуется поддерживающая команда менеджеров, продаж и управления проектами. Если у вас его нет, вы обязательно будете в «марше смерти». Даже если вы откажетесь от качества, процесса, тестирования и прочего, вы обнаружите, что для проекта никогда не хватает времени.
Таким образом, это возлагает бремя и риски, связанные с требованиями, на них, а не на вашу команду.Обратите внимание: чтобы добиться успеха в этих переговорах, вам потребуется поддерживающая команда менеджеров, продаж и управления проектами. Если у вас этого нет, вы обязательно будете в «марше смерти». Даже если вы откажетесь от качества, процесса, тестирования и прочего, вы обнаружите, что для проекта никогда не хватает времени.
В этой экономической среде много компаний конкурируют за небольшую работу. Кто-то обязательно сделает им очень выгодную ставку, которая
- Не сможет выполнить,
- Убьет их команду, или
- И тем и другим.
Когда они не могут выполнить поставку по согласованной цене, они начнут снижать качество, чтобы что-то доставить и получить деньги.
Ваша задача - профессионально представить этот факт вашему потенциальному клиенту и убедить его, что вы будете очень много работать, чтобы доставить товар по разумной цене. стоимости, но и доставить именно то, что им нужно. Тот факт, что вы возвращаетесь за более подробной информацией, и метод, которым вы подходите к проекту (гибкий ... но будьте уверены и объясните им преимущества для бизнеса), помогает гарантировать, что они получат то, что им действительно нужно.
Помните,
РЕДАКТИРОВАТЬ :
Обращение к ситуации с посредниками. Я думаю, что лучше всего было бы отправить список рисков вместе с вашим предложением в качестве любезности к покупателю. Вроде как предупредить их об ограничениях их проекта. Это будет стоить вам некоторой работы заранее, но я думаю, что это может помочь вам выиграть проект.
у вас есть два варианта,
сделайте наилучшее предположение и удвойте или утроите свою оценку (ваши конкуренты, вероятно, делают то же самое.)
объясните заказчику, что вы не можете предлагать такую работу, и скажите ему, что все остальные, которые дают ему фиксированную оценку, вероятно, не совсем правдивы.
в тот день, если вы не можете заработать на работе деньги, то нет смысла ее пытаться.
Лично я предпочитаю последнее,
Несколько вещей, о которых я бы сказал, вам следует подумать:
Предположения: Вы не можете добавить ни одного заявления об отказе от ответственности, но вам необходимо заполнить пробелы в требованиях разумными предположениями и задокументировать их. Ничего серьезного или пугающего, просто раздел в вашей спецификации / заявке со списком маркированных пунктов, говорящих о том, что вы считали правдой, чего не хватало (например, сведения о пользователях будут извлечены с помощью LDAP, и не будут написаны экраны администратора, чтобы покрыть пользователя-администратора) .
Это дает вам ясность в оценке, поскольку теперь у вас есть полный объем для работы, но это также означает, что если клиент возвращается с вещами, которые сильно отличаются, у вас есть справедливое основание, чтобы начать говорить о повышении запросов на изменение и варьируя стоимость. В качестве альтернативы они могут вернуться во время переговоров, заявив, что это предположение или что одно неверно, и у вас есть дополнительная информация.
Вне области: Конкретный случай предположений - перечислите вещи, которые вы не включаете (например, Никакой интеграции с системой X не будет). Опять же, это позволяет вам иметь полный объем и разумные основания для потенциально изменяющейся стоимости на более позднем этапе.
Предположения и выход за рамки особенно применимы, когда что-то упоминается мимоходом, но на самом деле не отслеживается, или для вещей, которые они скажем, можно подождать второй фазы. Часто это то, что, по мнению клиента, делается в рамках основного проекта, а команда проекта - нет.
Надеюсь, тщательность и понимание допущений и объема, которые вы определяете, также помогут вселить уверенность в конечного клиента. .
Непредвиденные обстоятельства: Сложный вопрос, но вы должны добавить непредвиденные обстоятельства двумя способами:
(1) для конкретных рисков. Для вещей, которые могут означать, что на что-то уходит больше времени, чем вы предполагали, положите сумму, чтобы покрыть это с учетом вероятности того, что это произойдет. Сложите все это, и вы получите непредвиденный риск.
(2) Дерьмо случается при непредвиденных обстоятельствах - в ИТ-проектах случается непредсказуемое дерьмо. Добавьте от 10% до 20%, чтобы покрыть это.
Скрываете ли вы непредвиденные обстоятельства от своих коммерческих людей и клиента или нет, зависит от ваших отношений, но если они будут устранены, они должны понять, что это означает (по сути, вы БУДЕТЕ перебегать).
Поймите взаимосвязь между усилиями и затратами : Ваша роль как технолога - дать оценку трудозатрат на основе имеющейся у вас информации. Затем вам необходимо сообщить об этом с предположениями, уровнем непредвиденных обстоятельств и т. Д. Вашей коммерческой команде, которая сможет преобразовать это в денежное выражение. С ними нужно четко понимать, что если они хотят снизить стоимость, это не повлияет на усилия.
Существует множество веских причин записывать стоимость для клиента (чтобы построить отношения, потому что в конечном итоге вы получите материал, который можно будет повторно использовать позже, и т. Д.), Но люди должны понимать, что, если объем не изменит усилие остается прежним - уменьшение происходит за счет прибыли.
У меня есть статья в блоге, в которой для вас может быть несколько советов:
http: // pm4web.blogspot.com/2009/06/surviving-under-resourced-project.html
один из других плакатов здесь имеет хороший смысл. Всегда найдется кто-то, кто предложит более низкую цену за работу. и разработчик пострадает из-за этого позже (т.е. ему придется делать много бесплатной работы, чтобы удовлетворить клиента).
некоторым клиентам необходимо иметь такой опыт, прежде чем он поймет, что вы не можете выполнять ИТ-проекты по дешевке, не заплатив цены.
LM
Стремитесь к реализму. Избегайте слишком больших обещаний, а затем сделайте это четко.
Многие клиенты были сожжены нереальными поставщиками, которые не смогли выполнить обещанное.
Подчеркните необходимость спринта спецификаций. Сосредоточьтесь на основных функциях и стремлении предоставить, а не на плюсе функций. Предложите начальную фазу разработки для реализации основных функций.
Расскажите о силе и безопасности гибкого подхода. Считайте клиента способным видеть здравый смысл.
Вкратце: старайтесь выглядеть реалистичным и серьезным (в большей степени, чем ваши конкуренты). В конце концов, для любого серьезного покупателя важнее всего не цена, а уверенность в том, что товар будет доставлен в срок и в рамках бюджета.