Оффшоринг программного проекта - разрешение конфликтов [закрыто]

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

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

Проект включал в себя такие вещи, как XMPP, RabbitMQ и Database. На моей первой встрече с ними (всегда IM) я подробно объяснил, что им нужно делать. Казалось, они понимают это - и они были очень уверены, что это будет сделано легко.

Все идет нормально. Но через неделю, когда мы встретились снова, они были полны недоразумений о том, что нужно было сделать. Когда я спросил одного из разработчиков, знает ли он XMPP, он сказал, что работает с ним впервые. На нашей первой встрече я особо упомянул сложность проекта и задействованные технологии. Кроме того, я неоднократно просил их написать функциональную спецификацию, как именно они это сделают. Но они сказали «НЕТ» и настояли на том, чтобы лучше написать код. Я сказал ОК.

Проект завершен через 3 недели, и они доставили то, что было нужно. В этот момент я начал пересматривать код. По большей части это было нормально, но есть некоторые важные проблемы:

• они жестко закодировали некоторые вещи, которые нужно было выделить в конфигурационный файл
• было несколько конфигурационных файлов, которые мне нужно было объединить в один
• они написали абсолютно никакой документации
• некоторые другие незначительные изменения

Я попросил их внести эти изменения (кроме документации) - и у нас был аргумент.

Они сказали, что, поскольку цена была фиксированной, я несправедливо просил их внести какие-либо изменения после того, как они закончили рабочий код. То, что они работали над проектом неоправданно долго, и теперь было совершенно неправильно просить что-либо.

Наконец, теперь они внесли изменения, и проект окончен. Но это оставляет некоторые вопросы в моей голове ...

• Они сделали то, что было нужно, но мне нужно, чтобы это было сделано правильно , и, следовательно, изменения. я был действительно несправедливым?

• Почему я согласился разрешить им кодировать, не имея функциональной спецификации?

• Почему я не убедился, что они все поняли с первого раза?

Кто-нибудь оказывается в том же положении? Как вы думаете, есть лучший способ управлять внешними проектами?

-- ОБНОВИТЬ --

Спасибо за все мнения - после размышлений на весь опыт, я могу сделать вывод ...

• Хотя я не был расплывчат в спецификациях со своей стороны, я, конечно, не делал их одержимыми, как предлагалось. Таким образом, выгода заключается в следующем: всегда будьте настолько конкретны, насколько это возможно - прочитайте свои спецификации также с их точки зрения и посмотрите, пропустили ли вы что-то. Повторите это по крайней мере три раза.

• Просто указать, что код должен делать, этого недостаточно. Вы должны указать, как должен выглядеть код. Какова будет структура каталогов; даже имена файлов, если это возможно. Это избавит вас от неприятностей позже. Строго укажите правила кодирования, соглашения об именах переменных, внутренний формат документации и т. Д. Следите за тем, чтобы они следовали этим рекомендациям, и, если нет, кричите.

• Требуйте функциональной спецификации с их стороны - настаивайте, чтобы она была написана перед любым кодом. Это поможет избежать путаницы и недоразумений.

• Просмотрите код в процессе его разработки, чтобы выявить аномалии ранее и исправить их. Поговорите с ними хотя бы раз в день.

• Наконец, попытайтесь установить с ними хорошие отношения. Заставьте их почувствовать, что вы цените их работу. Не заставляйте их преувеличивать, чтобы они соответствовали вашим рекомендациям - вместо этого попросите их сделать это и скажите им, что после завершения проекта вам будет намного проще поддерживать код.

Прежде всего, это не проблема оффшоринга, это проблема управления поставщиком.

Да, вы сделали МНОГО ошибок ...

Они сделали то, что было нужно, но мне нужно, чтобы это было сделано правильно, и, следовательно, изменения. я был действительно несправедливым?

Да, это справедливо. Если вы хотели, чтобы это было сделано определенным образом, вы должны были сказать это до согласования цены, чтобы они могли делать соответствующие ставки.

Почему я согласился разрешить им кодировать, не имея функциональной спецификации? Потому что вы не хотели платить за спецификацию! Документация отнимает много времени и стоит дорого, должны ли они делать это бесплатно?

Почему я не убедился, что они все поняли с первого раза?

Они поняли. Но на вашей первой встрече ПОСЛЕ того, как контракт был подписан (и фиксированная цена согласована), это когда вы ОБЪЯСНЯЛИ! Таким образом, необходимо сократить расходы (часы), где они могли бы .. В основном, проводя только одну встречу в неделю, не давая никаких вариантов путаницы.

Вот как это сделать в следующий раз ... В два этапа ...

Этап 1. Попросите их собрать требования, выполнить системный анализ и написать технический проект и / или функциональную спецификацию (или написать ее самостоятельно). Согласуйте цену для этой фазы. Обязательно объясните, что с вашей стороны нет обязательств дать им фазу разработки. Не забудьте указать время встречи в цене.

Фаза 2: Пусть они сделают ставку на разработанные на основе спецификаций теперь, когда они (и вы) имеют, и действительно знают, что усилия прилагаются Снова обязательно включите время для встреч в цену. Потому что включить небольшой дополнительный бюджет для изменений.

Редактировать: я хочу добавить дополнительную точку .. Здесь также виноват поставщик, часть его работы также поможет вам с управлением проектом, и даст вам знать, где есть недостатки в процессе.

Мне нужно было это правильно сделано

Тогда не передавайте это на аутсорсинг, или, если вы это сделаете, убедитесь, что они работают в вашей проектной команде и что вы участвуете в проверках кода в то время.

Проект завершен через 3 недели, и они доставили то, что было нужно. В этот момент я начал пересматривать код.

Опять же, вы должны были пересмотреть код во время проекта, а не после.

Они сказали, что, поскольку цена была фиксированной, я несправедливо просил их внести какие-либо изменения после того, как они закончили рабочий код.

Вы заплатили им фиксированную цену за рабочий код. К сожалению. Это не их вина, а ваша. Платите за их время, чтобы участвовать в спринтах, которые вы контролируете, и вы не столкнетесь с этой проблемой. Вы должны платить им за время и принятые пользовательские истории, а не за код.

На моей первой встрече с ними (всегда IM) я подробно объяснил, что им нужно делать. Казалось, они понимают это - и они были очень уверены, что это будет сделано легко.

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

Когда я спросил одного из разработчиков, знает ли он XMPP, он сказал, что работает с ним впервые.

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

Почему я согласился разрешить им кодировать, не имея функциональной спецификации?

Только вы можете ответить на этот вопрос сами, но в следующий раз примите это как учебный опыт.

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

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

По большей части это было нормально, но есть некоторые важные проблемы:

• они жестко закодировали некоторые вещи, которые нужно было выделить в конфигурационный файл
• было несколько конфигурационных файлов, которые мне нужно было объединить в один
• они написали абсолютно никакой документации
• некоторые другие незначительные изменения

Были ли эти вещи частью вашей спецификации? Если они были, это их вина. Если нет, то это ваше. Если было не совсем понятно, содержатся ли эти вещи в спецификации, то это также ваша вина, так как вы написали документ. Попробуйте написать лучшую спецификацию в следующий раз.

Я недавно сделал презентацию о оффшоринге. Он назывался «Глобальный аутсорсинг, 10 советов для расширения возможностей вашего бизнеса». Вот краткое изложение 10 советов (это может быть сделано до 400 внешних проектов):

Выбор

1. Избегайте самых низких и самых высоких участников . Это просто очевидно, вы не хотите рисковать с более низкими участниками, а наиболее продавцы, как правило, менее ценны (стоимость / цена), чем медиана.

2. Проверьте рейтинги (или ссылки) . Я всегда проверяю ссылки и рейтинги.

3. Расставьте приоритеты в мотивации . По одинаковой цене я выбираю ставку, которая была мотивирована. Например, предложение участника о правильности вашего проекта - очень хороший знак.

Б. Надзор

1. Защитите свою интеллектуальную собственность . Это одна из самых больших ошибок. Обычно обрабатывается используемой платформой (например, vworker или elance).

2. Отказаться от пользовательских рамок . Или вы рискуете быть привязанным к нему, или, точнее, разработчику, который это написал;)

3. Ввести стандарты . Относится к предыдущему совету. Использование стандарта увеличивает ценность вашего исходного кода, поскольку это понятно большему количеству разработчиков.

4. Обзор рано, обзор часто . Большинство проблем можно «скорректировать», если вы просматриваете исходный код после первой недели или работы.

C. Стратегия

1. Тест провайдеров с небольшими проектами . Прежде чем дать крупный проект поставщику, я проверяю его с одним или двумя небольшими проектами.

2. Принять несколько участников торгов, чтобы уменьшить риск . Для критического проекта я выбираю двух или трех претендентов, а затем выбираю наилучшую реализацию. Лучше всего работать с небольшими проектами (до 5000 долларов).

3. Собрать компоненты . Другая стратегия заключается в передаче компонентов, которые вы собираете позже, на внешний подряд. Одним из преимуществ является то, что вы можете легко переключаться между провайдерами, и ни один из них не может получить доступ ко всему (снизить риски для интеллектуальной собственности).

Я полностью согласен с ответом maple_shaft.

Вы приняли код, и я полагаю, выписали чек, затем просмотрели код, вы вроде как сделали все задом наперед.

Почему я согласился разрешить им кодировать, не имея функциональной спецификации?

Потому что ты не записал это в контракт. Поскольку вы хотели, чтобы работа была выполнена, вы приняли их причины, хотя именно это доставило вам неприятности.

Почему я не убедился, что они все поняли с первого раза?

Вы должны были предоставить им дизайн, который, по вашему мнению, сработал бы. Тогда это не имело бы значения, если бы они не поняли полностью. Я имею в виду, что вы не платили им за это, так кто же это сделает? Как этот код будет поддерживаться без какой-либо документации и спецификаций дизайна. Ответ, скорее всего , не будет .

Они сказали, что, поскольку цена была фиксированной, я несправедливо просил их внести какие-либо изменения после того, как они закончили рабочий код.

Вам повезло, что они сделали изменения, которые вы хотели. Они могли бы сказать: неудача

Кто-нибудь оказывается в том же положении? Как вы думаете, есть лучший способ управлять внешними проектами?

Конечно, другие люди находятся в вашем положении, иначе вся индустрия аутсорсинга не пострадает, многие компании начинают осознавать необходимость платить (или ждать), чтобы сделать это в 3 и 4 раза дороже, чем делать это правильно один раз. ,

По крайней мере, делая это самостоятельно, вы можете ежедневно проверять состояние проекта. Если вы позади, есть вещи, которые вы можете сделать, чтобы контролировать ущерб, по крайней мере, в теории.