Tired of outsourcing? Get hired at a top product startup from Silicon Valley 🚀
×Закрыть

Частые ошибки заказчика в Outsourcing

Пишу обзор самых частых ошибок в Outsourcing/Outstaffing, хотел бы узнать ваш опыт, кто с чем сталкивался. Опишите свой опыт в комментариях плиз.

Вот несколько примеров:

1. Заказчик редко отвечает на E-Mail и другие средства коммуникации -> команда долго ждет ответа заказчика и не может продолжить работу на проекте

2. Заказчик ставит задачу по E-Mail и думает, что команде все понятно -> в итоге заказчик получает функционал не совсем тот (или совсем не тот), что хотел

3. Заказчик дает слишком большой проект (например на 3-6 месяцев) и не контролирует в средине разработки -> в итоге, через 6 месяцев, заказчик получает функционал не совсем тот (или совсем не тот), что хотел

4. Заказчик не присутствует на demo (демонстрации готового функционала) или не просматривает статус апдейты и команда не получает feedback вовремя -> в итоге заказчик получает функционал не совсем тот (или совсем не тот), что хотел

5. Перед началом нового проекта заказчик не проводит Kick-Off и думает, что команде все понятно -> команда с самого начала понимает цели или реализацию проекта неправильно и в итоге тратится много времени на переделки

А какой у вас опыт?

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Распространенный пример: сайт сделала одна контора, потом с ней отношения прекращают и дальнейшую поддержку (и доработки) осуществляет фрилансер. С чем-то он будет несогласен — переделает. Где-то нагородит своих костылей (и будет прав, т. к. поддерживать — ему). Но и с этим человеком в процессе жизни сайта может не сложится.

А следующий спец скажет, что «все дорого» и тоже будет прав, т. к. ему придется исправлять (или вникать) костыли минимум 2-х разрабов, работающих до него.

А фирма которая изначально сайт делала может вполне сказать «мы не можем оказывать техподдержку проекту, т. к. после изменения вносил не наш разработчик».
Итог — редизайн, т. е. плата за разработку с нуля (если заказчику сайт реально надо).

Итак, 4-я ошибка — непонимание: кто что должен делать и разрыв отношений с «ключевыми» реализаторами проекта.

Рассчитывать на то, что все девелоперы в пределах своего уровня — jun/mid/sr — одинаково продуктивны. Или что продуктивность инженера на давно существующем проекте напрямую зависит от его квалификации: «поставим туда сеньора — он нам всё быстренько разгребёт».

И если человек въезжает медленно (медленно, но верно), то его снимают с проекта как раз тогда, когда он начинает что-то там понимать. Заменяют его новичком, которого надо с нуля вводить в курс дела на проекте, в надежде на то, что он разберётся во всём быстро.

Я пару месяцев обычно въезжаю в методы людей с которыми работаю. Зато потом с полу слова друг друга понимаем.

Это нормально. Видишь эти ошибки и объясняешь заказчику, как их нужно исправить. Если настолько тупой, что не хочет исправлять — ну он ССЗБ и идет на хутор за бабочками.

Ну или для любителей адреналина и поиметь бабло и ничего не делать такой заказчик — золотое дно.

Ошибка номер 3. Пытаться оценить стоимость проекта из предложений тех «кто продает». Хотите примерно знать сколько стоит работа в ИТ — спрашивайте у тех «кто покупает». Заведите хорошие отношения с фирмой похожей на вашу и спросите — во сколько им обходится услуги дизайна, разработки сайта, раскрутки, ведения товарной базы. Что из этого «друзья» делают своими силами, для чего привлекают специалистов?
«Заказываете у Пети? Давайте будем заказывать вместе. Специфика у нас одинаковая, так что и нам будет дешевле — и Пете лучше одинаковую работу делать.» Хотя Петя тоже оборзеть может :)

Еще одно решение — тендер. Скидываешь задачу нескольким и просишь оценить и предложить пути решения. Выбираешь того, кто больше понравился по результатам тендера.

Читал, что некоторые идут ещё дальше: превращают это в тестовые задания для кандидатов. :-)

Ну это уже зависит от степени извращенности. Но можно и так.

Угу, но если проект сделан силами разных разработчиков (незнакомых друг с другом) он будет накапливать в себе различные технические несовместимости. А селдить чтобы все было в одном ключе — нужен один но супер ТЕХНИЧЕСКИ грамотный руководитель проекта, а не тот кто прайсы на разработку умеет читать.

Ты о чем? какое это отношение имеет к тендеру?

Ошибка номер 2. Заказ большого проекта (сайта), когда нет опыта работы/заказов (полностью или частично) средне-маленьких. Сколько людей раньше писали (сейчас такого меньше вижу) «Хочу свой Амазон/Алиекспресс/Вконтакте». При этом люди даже бложик на ЖЖ или группу ВК никогда не вели.

Скажу сейчас банальную фразу: Заказчик всегда прав!
Со стороны девелопера нам часто кажется что заказчик делает кучу ошибок и из-за этого проект успешно скатывается в говно. Так же, как глядя на соседа мы часто считаем что он живет неправильно, а вот если бы стал вегетарианцем, медитировал, занимался спортом — то мог бы быть успешным... НО — все зависит от точки зрения!
Почему мы считаем что лучше заказчика знаем что ему надо?! Если у него есть деньги на ИТ проект (а деньги нужны немалые) — значит как минимум он бизнесмен (или менеджер) получше любого из девелоперов!
Это мы всегда думаем что заказчику нужен качественный, надежный софт, который прослужит много лет. А на самом деле ему может нужно просто построить «сочинский сортир» что бы распилить бюджет. Или может ему нужно доказать что аутсорс — говно, что бы кинуть другого менеджера и продвинуть свою команду. Или ему нужны «потемкинские деревни» что бы сделать презентаху и срубить инвестиций. Или нужно быстрее выпустить что-то, что бы застолбить место на рынке... В конце-концов только 20% софта использует 80% юзеров — а все остальное это малопопулярный «ширпотреб», который делают что бы через год выкинуть и забыть.
Представьте что вам нужно сделать ремонт. Если это ремонт в доме, в котором вам жить то наверняка вы будете искать хороших подрядчиков, смотреть эскизы, контролировать ход работ и и т.д. А если это ремонт в очередной квартире для сдачи в аренду? Тогда вам нужен «евроремонт» для галочки и подешевле — вникать в ход проекта вы не будете.
Так что зачастую не «заказчик ошибается, когда хочет купить китайские одноразовые тапки подешевле», а мы, которые думаем что ему нужны кожаные сапоги «на века». Чай мы не в ателье Кинсман работаем, а в подпольном цеху без оформления.

Менеджер тоже человек, а не супермен, и он тоже может быть некомпетентным или иногда при каких-то условиях допускать про... (провалы).

Если у него есть деньги на ИТ проект (а деньги нужны немалые) — значит как минимум он бизнесмен (или менеджер) получше любого из девелоперов!

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

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

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

ну если для вас аутсорс в одно лицо — это бизнес с управлением рисками, то да, тут каждый бизнесмен. на уровне владельца шаурмешной.

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

Це ще що за комплекс неповноцінності?
Розумний замовник проект в Україну не віддасть.
Якщо віддав на аутсорс в Україну — значить баран бараном.
Він не може бути правим, бо наробив дурниць із самісінького початку.

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

Скажу сейчас банальную фразу: Заказчик всегда прав!

Эх жаль ты не фигуристая девчонка с большими сиськами.

А що тут переживати? Замовник успішно витратить всі свої гроші, а ви підете працювати на кращий проект. Дурням ж закон не писаний.
Звучит як якісь недостартап.

Заказчик накидывает новые задачи в текущий спринт, который уже распланирован. Если команда не успевает, то он требует овертаймы. Приоретизация задач не ведётся.
Давай давай давай давай фигач. В сутках 24 часа — для кого?

Если команда не успевает, то он требует овертаймы.

На хер такого заказчика

На хер такого заказчика

Если он их по двойному рейту оплачивает, то вай нот?

Можно положить хер и получать за это по двойному рейту. Разве что так.

Ну это непрофессионально.
Плата за срочность — стандартная практика в практически любом бизнесе.
Работает, разумеется, если менеджмент исполнителя делится бенефитами от нее с работниками, а не делает морду кирпичем.

Зато офигенно. Сидишь в пустом офисе и играешь на компе.
Заказчику разводишь руками.

6. Заказчик не определил метрики которые влияют на успех продукта, и/или не договорился с командой как они будут отслеживаться
7. Заказчик не делится с командой статистикой по продукту (совсем запущенный случай — не настроен даже базовый трекинг показателей в Google Analytics / подобных системах)

Заказчик устанавливает дедлайн в одностороннем порядке

А кого интересуют ваши эстимейты 😀

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

Ну конечно. И потом отрицательная репутация обеим, не говоря уже о недоборе сумм. И что самая катастрофа — демотивация команды, выученная беспомощность.

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

Ну так то, что появилось в понимании — переходит на новый этап и за новые деньги. В чем проблема? Или вы считаете, что кто-то согласится в согласованный бюджет и сроки впихивать кучу дополнительной неоцененной работы? ))

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

а просто биллятся часы дальше

Ну то есть все дополнительные работы таки оплачиваются? Или что именно вы хотели сказать?

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

Так ведь и фичи не получит, пока не заплатит :) К тому же есть договор, в котором обычно прописаны условия выполнения работ. И впихивай требования, не впихивай, а если в договоре указано, что оплатить надо — оплатит. К тому же, если клиент и правда заинтересован в доработках, то ему желательно бы не портить отношения с компанией, которая занимается разработкой, так как он очень быстро может перестать быть клиентом. А на стороне скорее всего дорабатывать существующую систему никто не будет и придется оплачивать разработку с нуля. Правда это мы какой-то совсем уж клинический случай сейчас с вами обсуждаем.

обычно в договоре не описывается четкое ТЗ, а все что не описано повод для манипуляций... и к сожалению такая клиника встречается

В договоре ТЗ не описывается, да (для этого есть само ТЗ :) ). Но там есть перечень пунктов, согласно которым, работы должны быть оплачены.

Обычно приложением к договору идет для тяжелых случаев.

а есть вариант с естимейтом — клиент жмет — дайте мне быстрый естимейт на такую-то фичу на высоком уровне — ты даешь говоришь что вероятность что естимейт может изменится около 70% и планировать на основе него не стоит, но всем пох — и надо делать ибо клиент опять таки всем сказал что будет готово в тот-то срок, а между делом оказывается что там есть куча дополнительных изменений по ходу дела о которых никто не говорил

Аутсорс не аутсорс — если заказчик не относится серьезно к постановке задачи и контролю над ходом работ на выходе получаются странные вещи.

странные

я бы букву «т» убрал

Если бы заказчик был умный, он бы сам все сделал. Главная ошибка заказчика: ожидание того, что проект будет приносить прибыль потому что «я его придумал». Есть еще ошибки. Вспомню — напишу.

Таких «заказчиков» сразу в сад без 100% предоплаты. А зачастую и с ней.

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

Ну и вот.

Заказчик ставит задачу по E-Mail и думает, что команде все понятно -> в итоге заказчик получает функционал не совсем тот (или совсем не тот), что хотел

А менеджер зачем? Не для того ли, чтобы выяснить правильно ли поняли?

Заказчик дает слишком большой проект (например на 3-6 месяцев) и не контролирует в средине разработки

Кто мешает инициировать промежуточную демонстрацию, Ктулху?

Перед началом нового проекта заказчик не проводит Kick-Off и думает, что команде все понятно -> команда с самого начала понимает цели или реализацию проекта неправильно и в итоге тратится много времени на переделки

Вы блин что, дети малые? Звоним, спрашиваем.

Кто мешает инициировать промежуточную демонстрацию

Инициировать — никто. Но заказчик обсуждаемого типажа такую инициативу или молча проигнорирует, или ответит в духе «в ТЗ всё понятно написано, а конечный результат покажете, когда будет релиз (а пока не морочьте мне голову своими демками, я занят)»

Тогда ПМ должен намекнуть заказчику, дипломатично донеся мысль: «Нет, детка, придётся посмотреть на демо промежуточной версии. Ты ведь не хочешь, чтобы проект накрылся из-за какого-нибудь нежданчика, который ни ты, ни — тем более — мы не могли предусмотреть?»

Главная ошибка заказчика, что он вообще аутсорсит.

это еще, можно сказать, повезло, если всего лишь дважды...

И это правда. Как чаще всего случается, проект так и остаётся реализованным на троечку с минусом.

Нет, не то что аутсорсит, а что не понимает специфики работы с помощью аутсорса.

Ага. А если а разработка будет по месту локации заказчика, что-то изменится?

Разумеется. В случае проблем аутсорсер будет доказывать что не верблюд арбитражному судье.

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

Главная ошибка заказчика, ЧТО он вообще аутсорсит. Аутсорсить можно не-бизнесовые процессы, которые не являются особенностями бизнеса. Например, строя интернет-магазин без изысков, можно тупо натянуть шаблон и заказать услугу периодического администрирования на предмет апдейтов и прочей хрени.

А если строится IT-бизнес или там где IT-решения играют ключевую роль (например, доводят клиента до бешенства), там IT аутсорсить в общем случае нельзя, в исключительных — на условиях очень долговременного сотрудничества, когда дедлайн отсутствует как таковой.

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

Подписаться на комментарии