Розмежування програмного проекту - вирішення конфліктів [закрито]

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

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

Проект стосувався таких питань, як XMPP, RabbitMQ та Database. Під час своєї першої зустрічі з ними (завжди я) я ретельно пояснив, що їм потрібно зробити. Вони ніби це розуміли - і були дуже впевнені, що це буде зроблено легко.

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

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

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

Я попросив їх внести ці зміни (крім документації) - І у нас був аргумент.

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

Нарешті тепер вони внесли зміни, і проект закінчився. Але це залишає деякі питання в моїй свідомості ...

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

• Чому я погодився надати їм код без функціональних специфікацій?

• Чому я не переконався, що вони все зрозуміли вперше?

Хтось опиняється в тому самому становищі? Як ви вважаєте, чи є кращий спосіб керувати проектами, що передаються сторонніми компаніями?

- ОНОВЛЕННЯ -

Дякую за всі думки - після роздумів над усім досвідом я можу зробити висновок ...

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

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

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

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

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

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

Так, ви помилилися ...

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

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

Чому я погодився надати їм код без функціональних специфікацій? Тому що ви не хотіли платити за специфікацію! Документація забирає багато часу і дорога, чи варто це робити просто безкоштовно?

Чому я не переконався, що вони все зрозуміли вперше?

Вони зрозуміли. Але на кулачній зустрічі ПІСЛЯ підписаний договір (і фіксована ціна, погоджена) - це коли ви ПОЯСНУЄТЬСЯ! Тож потрібно скоротити витрати (години) там, де вони могли. В основному, проводячи лише одну зустріч на тиждень, не даючи жодних варіантів конфігурації.

Ось як це зробити наступного разу… У два етапи…

Фаза 1: Попросіть їх зібрати вимоги, виконати аналіз систем і написати технічний дизайн та / або функціональні характеристики (або написати це самостійно). Погодьтеся на ціну на цей етап. Обов'язково поясніть, що з вашого боку немає зобов’язань надавати їм етап розвитку. Обов’язково включіть у ціну час зустрічі.

Фаза 2: Запропонуйте їм подати заявку на розроблене на основі специфікації тепер, коли вони (і ви) мають, і дійсно знають, що зусилля залучені. Знову не забудьте включити в ціну час зустрічей. Тому що для включення невеликого необов’язкового бюджету на зміни.

Редагувати: Я хочу додати додатковий пункт. Тут постачальник також винен, частина роботи там занадто допомагає вам керувати проектом, і даватиме вам знати, де в процесі є короткий час.

Мені потрібно було це правильно зробити

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

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

Знову ж таки, ви повинні були переглянути код під час проекту, а не після.

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

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

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

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

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

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

Чому я погодився надати їм код без функціональних специфікацій?

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

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

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

Здебільшого це було нормально, але є деякі важливі проблеми:

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

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

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

Вибір

1. Уникайте найнижчих та найвищих учасників торгів . Це просто очевидно: ви не хочете ризикувати з нижчими учасниками, а найвищі учасники, як правило, менш цінними (ціна / ціна), ніж медіана.

2. Перевірте рейтинги (або посилання) . Я завжди перевіряю посилання та оцінки.

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

B. Нагляд

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

2. Відмовтеся від спеціальних рамок . Або ви ризикуєте прив’язатись до нього, а точніше до розробника, який це написав;)

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

4. Переглядайте рано, переглядайте часто . Більшість проблем можна «відкоригувати», якщо переглянути перший код після першого тижня або на роботі.

C. Стратегія

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

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

3. Зберіть компоненти . Ще одна стратегія полягає в аутсорсингу компонентів, які ви збираєте пізніше. Одна перевага полягає в тому, що ви можете легко перемикатися між провайдерами і жоден насправді не отримує доступ до всієї справи (зменшуйте ризики інтелектуальної власності).

Я повністю згоден з відповіддю maple_shaft.

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

Чому я погодився надати їм код без функціональних специфікацій?

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

Чому я не переконався, що вони все зрозуміли вперше?

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

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

Вам пощастило, що вони внесли потрібні вам зміни. Вони могли сказати: жорстка удача

Хтось опиняється в тому самому становищі? Як ви вважаєте, чи є кращий спосіб керувати проектами, що передаються сторонніми компаніями?

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

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