Неадекватно обиженные — 2. Разработчик не виноват.

В посте jonas’а мы можем увидеть типично менеджерский взгляд на возникающие проблемы между разработчиком и компаниями в процессе работы над проектами. Я сразу скажу, что не собираюсь оспаривать какие-либо выводы автора или доказывать свою правоту, а просто представлю ситуацию с другой точки зрения. 1. Противоположный взгляд на проекты. Итак, весь оффшорный аутсорсинг это работа на конкретного клиента, это выполнение его пожеланий и предпочтений. Его деньги – наш сервис. Как верно замечает jonas, успешное развитие аутсорсинговой компании в данном случае возможно лишь при установлении практически личных отношений с клиентом, превращении Джона Джефферсона Смита в просто Джона. Вы будете отправлять ему в аттаче к репортам поздравления ко Дню Благодарения и Рождеству, а он порекомендует компанию своим знакомым, да и сам при случае будет обращаться за выполнением очередного проекта именно к вам. Сэйлсы, как могут, обхаживают такого потенциально милого клиента, менеджмент планирует расширение офиса, сам Джон считает сэкономленные за счёт найма аутсорсеров деньги, и в результате все довольны – и продавец и покупатель. Осталось только разработчика представить и дело в шляпе. Но вот оказывается, что проект совсем неинтересный, и девелопер водит носом и занудничает, что ваш PHP он ещё в детстве отлюбил, а от на maintenance даже хомячки через пару месяцев с тоски дохнут. "Конфликтная ситуация налицо и, в большинстве случаев, дело кончается конфликтом и увольнениями". С одной стороны да, разработчик вполне вероятно несколько потерял связь с реальностью, и ему самооценка уже ходить мешает. Но с другой стороны, если человек действительно перерос этот уровень, если его используют, грубо выражаясь, для затыкания дырок? Если квалификация работника выше или хотя бы банально отличается от необходимой, как очень часто бывает? Или наоборот, сколько случаев – когда один разработчик висит сразу на пяти проектах, так что голова кругом идёт, или сидит в командировках месяцами, про которые никто, кстати, не спешил упоминать. У менеджмента на всё это ответ обычно прост и ясен – тебя, парень, наняли работать, а не выбирать, так что иди, сынок, работай, пока солнце ещё высоко. Ну и поработает нормальный человек над этим унылым "не своим" проектом, достанет он его в конец, и пойдёт он искать новое место работы. Но проблема в том, что его то не отпустят просто так. Где же ещё найдёшь второго такого, да и как клиенту объяснишь? Начинаются попытки удержания, какие-то аспекты выплаты зарплаты или там распределения всплывают и т.д. В результате, скандал, разборки и взаимная ненависть. А ведь можно было предугадать ситуацию, попытаться или подобрать более подходящий кадр на проект, или просто всё-таки заинтересовать человека. Хотя бы деньгами, ведь в нашем мире материалистов это тоже важно, не только в интересностях дело. В конце концов, что в данном случае вообще делал менеджмент до самого конфликта? 2. Сертификация "Сертифицированный спец - не обязательно крут. Сертификат это всего лишь подтверждение ваших знаний о предмете сертификации, но это ничего не говорит о том, что вы умеете применять эти знания на пользу проекту. Сегодня у вас успешно прошла сертификация, в чем разница между вами "вчера" и "сегодня"? С точки зрения руководства компании ее, извините, пока нет. Она появится тогда, когда вы поможете, компании заработать больше денег." Не стоит забывать, что сертифицированный специалист - более востребованный товар на рынке, и любой клиент с гораздо большим удовольствием будет платить за сертифицированного разработчика, чем просто за какого-то классного кодера Васю из далёкой и неведомой Беларуси. Вполне вероятно и платить согласятся за сертифицированного девелопера больше. Так что выгодна компании сертификация сотрудников и деньги ей она дополнительные приносит, здесь не надо лукавить :). А во избежание конфликтов, стоит чётко разъяснить программисту все условия, бонусы и минусы прохождениям им сертификации, о чём у нас тоже как-то иногда забывают. 3. Процессы Сейчас стало модно говорить про налаженные процессы и сертификацию компании по всевозможным ИСО 9001, CMMI и т.д. Именно эти процессы разработки проектов, документации, коммуникации внутри компании и должны определять эффективность её работы. Насчёт самого девелопмента, то здесь при желании можно неплохо всё задокументировать и воплотить в жизнь, а вот организовать удачную коммуникацию зачастую оказывается гораздо сложнее. В результате и получается ситуация, когда HR фидбек не донёс, прожект менеджер не рассказал ситуацию, а высшая сила была занята и не в курсе. На выходе – конфликты, провалы, непредвиденные овертаймы и т.д. Задача всё это правильно организовать лежит именно на менеджменте, и если количество конфликтов и всевозможно обиженных в компании достаточно велико, значит, тут уже не HR виноваты или программисты зарвались, а что-то у высшей силы не в порядке, где-то она не дорабатывает. Я, кстати, не отрицаю, что за последние пару лет с в связи с дефицитом специалистов число не очень адекватно оценивающих свои знания, умения, а главное амбиции разработчиков значительно увеличилось, и иногда просто жалко проектов и коллег, которые вынуждены мучиться с такими недокодерами. Но, тем не менее, менеджмент, и в первую очередь топ, в данном случае не просто высшая власть, а также ещё и обслуживающий персонал, который должен организовать и работу девелоперов и сейлсов и HR. Не просто свести между собой заказчика и девелопера, и пускай дальше сами в своём коде разбираются, а организовать процесс. Так что в конфликтах, текучке кадров и провале проектов виноваты не только разработчики, но и менеджмент тоже не в последнюю очередь.

Место солидарности беларусского ИТ-комьюнити

Далучайся!