Хотите начать свой бизнес, но не знаете с чего начать? Обратитесь к нам
Подписаться RSS / Email

Ужас-ужас-ужас или просто ужас? Первые проблемы владельцев аутсорсинга

7

fearВ публичный дом приходит посетитель — стра-а-ашный, аж жуть! Без содрогания сердца на такого и не взглянешь. Но что делать! И мадам отправляет к нему девушку. Через пару минут девушка пулей вылетает из комнаты и буквально слетает по лестнице, на ходу причитая: "Ужас! Ужас! Ужас!".

Тогда мадам отправляет к нему вторую девушку. Через минуту-другую сцена повторяется: девица чуть не кубарем слетает с лестницы, шепча в страхе: "Ужас! Ужас! Ужас!"

Мадам отправляет к нему третью девушку, но исход тот же: "Ужас! Ужас! Ужас!"

Что делать! Желания клиента — закон. И Мадам отправляется к нему сама. Девицы со страхом сгрудились внизу в ожидании того, что же сейчас произойдет. Но проходит две минуты, пять минут, десять, пятнадцать... В конце концов через двадцать минут мадам выходит из комнаты, победоносно спускается по лестнице и обращается к своему трудовому коллективу: "Ну, что?! Ну, да! Ну, ужас! Но не "ужас-ужас-ужас"!" :)

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

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

Предупрежден, значит вооружен.

Выражаясь категориями этого анекдота разделим проблемы на три группы важности по их возрастанию:

"Просто Ужас":

  • хаос и "беспорядок в танковых войсках"

Первые действия, скорей всего, будут хаотичны и не системные. Вы будете нащупывать свой личный стиль работы как с заказчиками, так и с исполнителями. Будете делать несколько копий ТЗ и оценок задач. Ваш рабочий стол (виртуальный и реальный) и почтовый ящик будут похожи на квартиру после вечеринки старшеклассников. Точно также вам будет сложно располагать и планировать свое время, так как не будете знать когда и на каком участке вашего дела вы вдруг понадобитесь.

  • дилемма офиса: нужен ли он?

Если ваша команда работает удаленно в разных городах, то вопрос не возникнет. А если в одном городе? Продолжать работать удаленно? Или снимать офис тратя и так скудные ресурсы подставляясь под проверки?

"Ужас-Ужас"

  • как управлять и мотивировать сотрудников

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

  • исполнители не делают вовремя задания, срывают сроки

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

  • заказчики становятся начальниками и командуют когда и что вам делать

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


"Ужас-Ужас-Ужас"

  • пускать ли разработчика напрямую к заказчику или нет?

Решать все мелкие вопросы и доделки проекта исключительно через вас/менеджера или давать доступ к "телу" разработчика заказчику? Отвлекаться от более важной деятельности по каждой такой мелочи? Или рисковать тем, что разработчик и заказчик станут работать напрямую минуя или  просто плести против вас заговор? Также есть угроза, что заказчик напрямую замучает разработчика без вашего ведома мелкими и крупными правками и функциональностями.

  • заказ взят, а делать некому, клиент уже нервничает

Вы уже взяли заказ, а ваши разработчики ушли (вообще или в отпуск) или перегружены? Расстраивать клиента не хочется и предоплату отсылать как-то глупо? А самому некогда делать или не владеете технологией?

  • как бы дожить до зарплаты-расплаты

Если ваши сотрудники на ставке, то раз в месяц у вас будет повод для беспокойства: как выплатить сотрудникам зарплату вовремя и в полном объеме. Увы, сотрудники не владельцы, они святым духом и идеями не питаются :)

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

Отправляясь в поход, возьмите дождевик ;)

Создано 22.08.2012
ПОНРАВИЛОСЬ ПРОЧИТАННОЕ? ПОЛУЧИТЕ КНИГУ-РУКОВОДСТВО ПО СОЗДАНИЮ IT АУТСОРСИНГ КОМПАНИИ НА ПОЧТУ!
Как найти первых сотрудников и заказчиков? С чего начать? В книге описаны основные шаги и принципы, которые помогли мне создать свою компанию.
Комментариев: 7

Комментарии   

 
Павел
#7 Павел 03.04.2014 12:09
Цитирую Евгений:
Проблемы-то обозначены правильно, а вот как насчет предложений по снижению риска возникновения этих проблем. Или проще - что делать, если одна или несколько их этих проблем все же возникли? Может быть есть какие-то know-how или best practices?


Евгений, предложите два самых больших страха. Напишу статью.
Цитировать
 
 
Евгений
#6 Евгений 03.04.2014 11:55
Проблемы-то обозначены правильно, а вот как насчет предложений по снижению риска возникновения этих проблем. Или проще - что делать, если одна или несколько их этих проблем все же возникли? Может быть есть какие-то know-how или best practices?
Цитировать
 
 
Павел
#5 Павел 24.01.2013 10:30
Цитирую Антон:
Давай заказчику доступ к разработчикам опасно. Во первых заказчики могут пролкнуть разработку нового функционала, по цене старого. Возможность работы с исполнителями увеличивает соблазн отнестись несерьезно к составлению ТЗ,да и банально могут переманить сотрудника к себе. В условиях нестабильной оплаты это легко сделать.

Все же зависит от заказчика и тип работ. Особенно в случае dedicated team и T&M, по-моему, вполне адекватный вариант. У меня так несколько сотрудников и даже команда работает.
Цитировать
 
 
Алексей
#4 Алексей 01.01.2013 12:56
Отправляясь в поход, возьмите хорошую мембрану (от westcomb, например), чтобы не вымокнуть в недышащем дождевике раньше, чем кончится настоящий затяжной дождь или метель ;)

1. Кто знает переманённых т.о. разработчиков, или переманивших заказчиков?
Кто может о них рассказать и раскрыть сопутствующие факторы?
Или рассуждения выше - продукт центров тревоги в мозгу, которых раз в 10 больше "центров мышления" и "центров удовольствия" (и если не контролировать первых, то они задавят вторых и третьих сигналами)?

2. Почему заказчик иногда пытается обратиться напрямую к разработчику?
Может его просто не слышат и не хотят, потому что решают свою проблему, а не заказчика?
Или может потому что аналитик не взял интервью у сотрудников, отвечающих за бизнес-процессы у заказчика?

3. Переманённый разработчик остаётся без команды, в которой работал. Что он может без этой среды? Кем он станет через год, 3, 5 без неё?

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

5. Проект - временное мероприятие. По его завершении разработчик снова идёт искать работу?

6. Большой программный продукт профессиональны й разработчик сделает за неподходящее заказчику время. И если разработчик не силён в дизайне, то сотрудники заказчика станут мышами, которые плакали, кололись и продолжали жрать кактус. Потому что человек, представляющий интересы заказчика, в 99% случаев не проверяет на себе инструмент в боевых условиях и не может это сделать.

7. Почему нельзя отделить продажу и разработки? Почему конечный акцепт "таки да, делаем это за такую сумму и время" после достижения всех договорённостей о деталях и работах не может ставить именно владелец аутсорс-компани и?

Да, заказчик часто хочет обойти схему продаж аутсорс-времени разработки, потому что ему кажется, что так он получит выгоду. Локальную. На сколько шагов вперёд он просчитал последствия для своего бизнеса от такой локальной победы? Договориться о функционале с заказчиком могут и должны аналитик и архитектор продукта/проект а. И сделают это быстрее и надёжнее, потому что именно им доступна инфа по инструментально й части и о проблеме заказчика. Затем этот договор о функционале можно передать продажнику. Почему о таком процессе не договориться и не построить заранее внутри аутсорс-компани и?
Цитировать
 
 
Сергей
#3 Сергей 25.08.2012 14:15
У меня на этот счет такие мысли:
- контакт непосредственно го разработчика с клиентом может иметь место, но должен быть максимально контролируем и формализован. Например в рамках таких систем, как Jira, bugzilla и тп. В случае, если ваша компания предоствляет еще и сервис по обслуживанию, то через различные Service Desk-системы. Главное, что бы любой "чих" был задокументирова н и зафиксирован. В идеале, клиент должен контактировать либо, со старшим разработчиком, либо с руководителем проекта с вашей стороны. Изменения в ТЗ должны вносить только они.
- офис на определенном этапе нужен обязательно. Как минимум для общения с начальниками ИТ и инженерами больших клиентов: они это любят. ;) При чем обстановка должнабыть расслаблено-тво рческой. Проще их "раскрутить" на более неформальный метод общения. ;) Это позволит больше узнать внутренней "кухни" клиента. Может в последствии пригодится.
Так же офис нужен вам, как руководителю. В домашних условиях далеко не всегда есть возможность нормально работать.
- если клиент начинает манипулировать своей значимостью, то, возможно, в самом начале не установили некоторую формализацию в отношениях. Она должна быть, особенно с крупным клиентом. Четко должнобыть прописано в договоре, кто, кому и в какие сроки должен. Естественно, не надо впадать в крайности и тупо следовать букве договора: относительно простые вещи можно слелать "за так": и клиенту приятно и вам необременительн о. В противном случае ему будет некомфортно с вами общаться. Однако, я считаю, что если у вас с клиентом, приносящим 80% дохода, долговременный контракт имеет смысл со временем создать под его нужды выделенную (так ему должно казаться ;)) команду. Так де постараться донести до него, что ИТ-сервисы не то же самое, что сервис по уборке помещений, а партнер, облегчающий ему процесс зарабатыванич денег.
- деньги на определенном этапе перестают быть мотивацией, многим настоящим ИТ-шникам важно иметь еще и интересные проекты или изучать что-то новое. Эти люди - ваш главный капитал. Именно они смогут, если что, подтянуть основную массу народа. Правда, очень часто ими тяжело управлять, но это уже дело вашего авторитета. К сожалению, в основном технического. "Качайте мозги".
И надо дать людям нематериальную мотивацию: банально быть лучшими в данной геграфической точке или предметной области.
- если схватились за заказ, а лелать не кому ищите, либо партнера на это заказ, либо фрилансера. И дайте ему не все, а только тот кусок, на который нет ресурсов, но руководитель проекта должен быть ваш.
Цитировать
 
 
Антон
#2 Антон 23.08.2012 09:38
Давай заказчику доступ к разработчикам опасно. Во первых заказчики могут пролкнуть разработку нового функционала, по цене старого. Возможность работы с исполнителями увеличивает соблазн отнестись несерьезно к составлению ТЗ,да и банально могут переманить сотрудника к себе. В условиях нестабильной оплаты это легко сделать.
Цитировать
 
 
Ксения
#1 Ксения 22.08.2012 13:28
Да, прям все четко по больным местам :)
Цитировать
 
Написать комментарий


Защитный код
Обновить