Об удаленной работе. Работа с аутсорс

в 6:53, , рубрики: аутсорсинг разработки, Карьера в IT-индустрии, оптимизация ресурсов, работа в регионах, управление проектами и командой, метки: , ,

    В сегодняшние дни, в дни опять нагрянувшего кризиса, важно сохранить бизнес, не потерять его. Как минимум большинство компаний ставит своей целью если и не расшириться, то хотя бы сохранить бизнес в том же состоянии, что и год назад. Одним из факторов поддержки выступает оптимизация, кадровых и денежных ресурсов. Всем хочется лучше кадров за меньшие деньги. Если с традиционным производством, где работа ведется в цехах и заводах работники должны непосредственно приходить на рабочее место и работать, то в новых (относительно традиционных) сферах экономики, связанных с Интернетом – такое правило не обязательно. Глобальная всемирная сеть позволила огромному количеству людей из IT объединится и создавать что-то новое. Вспомните как много у нас открытого ПО, и ведь эти люди, разрабатывающие его, никогда не сидели вместе в офисе, и что немаловажно – никогда не видели друг друга (в большинстве случаев). Почему же современные бизнесмены новых сфер производства пренебрегают этим преимуществом? Почему не используют внешние кадры, которые находятся удаленно от основного офиса? Но с другой стороны многие поняли всю выгоду данного положения и пользуются ими, к сожалению, таких меньшинство.

    Итак, что мешает начать работать с аутсорс кадрами при разработке ПО (сюда я включаю такие должности как разработчики, тестировщики, аналитики, тех.писатели и возможно некоторые другие):
1) боязнь нового;
2) страх, что внешние ресурсы завалят проект;
3) мысли о невозможности нормальной коммуникации внутри команды;
4) невозможность контролировать рабочий процесс.

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

Боязнь нового.

    Это психологический аспект, и он естественен, особенно для людей, у которых есть основной бизнес не из ИТ, а ИТ это поддерживающая структура. Тут наверно сложно объяснить почему есть боязнь, скорее всего это в большей степени сочетается с 4 пунктом. Эти люди привыкли держать всё в своих руках. Возможно это и правильный подход, но не оптимальный. Держать всё в курсе, контролировать процесс – это пустая трата времени. Необходимо контролировать результат, а не процесс. Т.к. не являюсь психологом, думаю оставить этот пункт.

Внешние ресурсы завалят проект.

    Опять возвращаясь к предыдущему абзацу повторюсь – необходимо контролировать результат, на каждом этапе. Особенно если идет работа с этой компанией впервые. И тогда неожиданностей через полгода работы: «а где проект?» не возникнет. Однако это не значит, что нужно каждый день спрашивать результат, эти запросы только отнимут время и у заказчика, и у исполнителя, а это время, которое могло бы быть потрачено на действительно необходимые вещи. Однако, если видно, что сроки срываются, вот тут стоит сделать какие-то телодвижения в сторону того, чтобы повлиять на процесс или отказаться от этого поставщика ресурсов. Кстати, срыв проекта естественен и для команд самого заказчика, внутри той же компании внутри могут происходить срывы сроков. Поэтому разделять команды на свои, и чужие по этому признаку «вдруг сорвут сроки» неправильно.

Коммуникация внутри команды.

Если команда разделена на несколько частей – это безусловно усложняет коммуникацию, однако если каждая команда делает свою часть, как можно более независящую от другой – это не проблема. Внутри каждой команды коммуникации будут без проблем, а коммуникации между командами будут происходить на уровне архитекторов и тим-лидов. Что касается коммуникации между аналитиками и разработчиками, мол без вербального общения никуда – тут поможет скайп и грамотная документация. Вот на документации я бы хотел остановится подробнее. Главное в проекте это документ (без бумажки – ты букашка). Действительно, чем подробнее напишет аналитик, тем меньше вопросов со стороны разработки. С другой стороны, если аналитик, что-то объясняет разработчику и потом забывает внести это в ТЗ, это грозит непониманием в будущем и дополнительными временными издержками. Представим ситуацию, аналитик написал часть какого-то ТЗ (ЧТЗ), по этому ЧТЗ разработчик начинает работу и у него возникает несколько вопросов. Если команда разделена и разработчики сидят в другом офисе/городе/стране то скорее всего он напишет письмо и получит задокументированный ответ в виде исправленного ЧТЗ или в крайнем случае в ответном письме. В этом случае требования, дополненные аналитиком сохранятся и их можно будет повторить, переслать, передать. Если же (а это касается больше традиционных команд) аналитик в одном офисе с разработчиком, то тут возникает опасность устного объяснения, что может привести к печальным последствиям:

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

    Но тут я уже увлекся. Это я к тому, что хорошо описанное ЧТЗ избавляет от массы ненужной коммуникации, поэтому этот этап исключительно важен. Ну, а все остальные коммуникации легко решаются с помощью электронной почты и скайпа. Конечно этот вид работы, который я описал, сводится к тому, что всё же разработчики сидят все вместе, но, просто, удаленно.
    И еще дополню по этому пункту небольшой расчет. Допустим всё же есть необходимость общения с заказчиком непосредственно со стороны разработки. А общаться будет же не вся команда, а только один человек, часто это тимлид. Так вот недельная командировка одного человека в Москву это порядка 35-40 тысяч рублей. Смешно же! Даже если раз в месяц отправлять человека в командировку, это дешевле, чем платить разницу этому специалисту в Москве и в регионе. Что уж говорить о целой команде?

Невозможность контролировать процесс

    Перейдем к последнему пункту: невозможность контролировать процесс. Я уже упоминал о нем. Действительно, есть ли необходимость контролировать процесс и лезть в разработку? Мы знаем, что в большинстве своем программисты замкнуты и не любят лишнего внимания. А когда они сидят отдельно от вечно болтающих менеджером и тихонько «кодят в углу», то это создает идеальные условия для того, чтобы сосредоточится и работать. Нужно ли программистам внимание руководства? Нет. Нужно ли руководству вмешиваться в разработку? Нет. Отсюда виден только один вывод – контролировать процесс собственнику бизнеса – не нужно, контролировать необходимо результат. А руководить командой и координировать работу будет тимлид, разделение по ролям в чистом виде.
    Что же, выходит страхи напрасны? Абсолютно. Это новая сфера экономики, огромный пласт, самая быстро развивающаяся отрасль экономики. И надо идти в ногу со временем и понимать новые возможности, которые открываются в связи с этим.

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

    Преимущества, если работать с аутсорс-компаниями:
  1. нет необходимости контролировать процесс;
  2. дешевле нанять один раз и забыть, чем держать штат;
  3. нет необходимости заботится о рабочих местах, о технике, зарплатах и прочих офисных деталях, а также о мотивации сотрудников;
  4. легко проверить результат, сравнив предоставленное решение с исходными требованиями (тут конечно спорно, допустим если само же составление ТЗ отдано на аутсорс).

    Преимущества если работать с филиалами:
  1. нет необходимости контролировать процесс;
  2. дешевле держать филиал разработчиков в регионе, чем в столицах (Мск, СПб) и по зарплате, и по аренде, и по остальным показателям;
  3. если с филиалом возникнут трудности, его можно закрыть;
  4. кадры в регионах не перегреты, поэтому за меньшие деньги можно получить отличных специалистов уровня не ниже столичных, а зачастую и выше, при этом значительно дешевле.

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

    Почему я всё это пишу? Я молодой специалист, который не хочет ехать в Москву. Я хочу работать на родине и получать достойную финансовую компенсацию за свои труды. Сейчас огромное число ИТ-компаний в Москве и что-то маловато филиалов этих компаний в регионах. Сужу я по своему городу-миллионнику. Филиалы есть, но их мало. У нас огромное количество кадров (программистов или около того) выпускается и такое же огромное количество уезжает в столицы или за рубеж. Всё потому, что там перспективы выше. Всё что нужно, чтоб сохранить кадры здесь – открывать филиалы. Я искренне надеюсь быть услышанным, и надеюсь, что конкуренция в нашем регионе позволит развиваться ИТ у нас в городе и в республике в целом. А это в свою очередь приведет к увеличению числа крутых программистов в городе и новому интересу со стороны работодателей.

P.S. Возможно я что-то упустил, буду рад обменятся мнением в комментариях.

Автор: zildarius

Источник

Поделиться новостью

* - обязательные к заполнению поля