Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

О чем молчат сотрудники аутсорсинговых IT-компаний: о проблемах в работе IT-компаний

В апреле 2017 года мы провели опрос среди украинских IT-компаний о ключевых проблемах в IT, которые мешают работать.

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

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

В опросе поучаствовали 25 компаний, в том числе члены Днепропетровского IT-community. В числе участников опроса компании Luxoft, Workrocks, Sitecore, Dataart, Archer и другие.

В таблице представлены данные от 1 до 10, где 1 — самые приоритетные проблемы, а 7-9 менее актуальные.


Sales only

PMs & Sales

PMs & Devs & QA

PMs & Devs

Продажи

Качество продукта

Сроки

Эстимация — проблема, которая волнует всех и набрала больше всего голосов, и что важно, она волнует и Sales и PMов и инженеров.

Какие конкретно проблемы эстимации волнуют всех:
1 — оценка проекта: методы, взвешенная точность, как работать с разработчиками, assumptions and risks, буфферы, cover your back, but be transparent, adjust client’s expectations / estimate perception
3 — как продавать клиенту реалистичные оценки


1 — cost+ модель — зачем она нужна, когда выгодна и кому
2-3 — как продавливать повышение цен клиентам с которыми уже работаешь
2-3 — как регулярно пересматривать рейты
4-6 — большое кол-во ответов «not interested now» — как с этим работать / конвертировать в delayed sale
4-6 — как и зачем продавать клиенту TM даже если умеешь успешно делать FP
4-6 структура сейлз отдела — имеет ли смысл разделять lead gen и closers по разным функциональным обязанностям и мотивационным моделям
7 — discounts — когда давать, когда нет, что получать взамен

1 — как продать клиенту автотесты, ROI, metrics
2 — зачем ПМу математика — анализ потраченного времени, тренды, планирование, что можно извлечь из анализа и трекинга. использование данных addressing client’s escalations
2 — клиент пытается продавить свои условия — время, деньги, формат выплат, сроки остановки команды (advance notice) — как с этим работать
5-6 — Где граница роли ПМа в общении с заказчиком — upsale через PMов

1-2 — на проекте «нет времени/бюджета» на архитектуру / рефакторинг / тесты / CI — что делать, как «добыть время» и не забросить продукт. заметные улучшения малыми точечными усилиями
1-2 — вся команда «разбросана». можно ли так работать эффективно (и что нужно для этого от ПМа), каков на самом деле overhead, зачем это делать (какие плюсы)
3 — Эффективные мониторинг и работа с логами — (например Zabbix, Kibana+Elasticsearch), insights, которые может получить ПМ и команда эффективно анализируя логи
3-4 — когда пора вводить в проект аналитика, нужен ли аналитик на небольших проектах и как закрывать активности этой роли если его нет
3-4 — документация — как, когда, в каком объеме, как продать
4-6 — code review — как, когда, кем, в каком объеме + tools
4-6 — Continuous Integration and Delivery — как внедрить быстро и поддерживать. Необходимые Mind and tech changes + tools
4-6 — можно ли клиенту работать с разработчиками напрямую. возможные причины запроса (trust, fraud, ...), implications, pors and cons, когда это возможно, а когда не стоит, как отказать корректно
5-6 — мы будем тестировать на нашей стороне, почему вы пишете с багами и другие возражения при продаже QA. как и когда продавать / upsale QA service. QA как «foot in a door»
7-9 — как продавать TM чтобы выгодно было и клиенту и нам
7-9 «addressing client’s escalations»
7-9 — зачем клиенту и команде аналитик. когда и как продать. SA как «foot in a door»
7-9 — как работать с freelancers / sub-vendors чтобы не страдало качество и надежность
7-9 — как ПМу и команде работать с аналитиком. как настроить interactions и процесс. зачем нужны формальные требования и в каком объеме. Requirement life cycle + tools

1 — Как подавать команде образ заказчика, его negative feedback, сжатые сроки, не всегда рациональные решения чтобы раздражение команды не росло и отношение к заказчику в целом не портилось, не росла неприязнь
2 Митинги, коллы и совещания
«daily standups, calls w/clients, calls w/analyst, отчеты в issue tracker и daily reports
„„сколько можно?! зачем все это нужно?! когда вообще работать?!““ — ответы на вопросы раздраженного разработчика, что получается без meetings и трекеров и почему это нужно не только ПМу»
3 — «plans are created to be changed» (как работать с планированием и client expectations в условиях «реальной жизни» :)
4 — setup инфраструктуры проекта на ранних этапах (первые недели проекта, honeymoon, project skeleton, CI)
5 — как сделать деплой быстрым, регулярным и безболезненным — тех и buz факторы / сложности
6 — конфликт backend vs frontend & client app teams (tech lead is backend dev)

Какие выводы можно сделать из описанного опроса — конфликт интересов между разными сторонами внутри компании приводит к тому, что страдает клиент и топ-менеджмент компании. Потому что клиент в конечном итоге не получает проект во время, а топ-менеджмент продолжает платить сотрудникам зарплату, несмотря на проблемы в проекте.

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

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

Решения для этих и других проблем будут озвучивать спикеры ITEM во время докладов. Смотреть программу ITEM

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
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

Хорошо, что провели такой опрос! Он просто показывает насколько у наших компаний односторонний взгляд, согласна с комментом Beaver Green. И для конфы есть 2 варианта:
1) давать ребятам то, что они хотят — инструменты и кейсы, как разрулить ситуацию,
2) изменить подход к позиционированию компании и сервиса
И хотелось бы, чтобы акцент делался на (2). Однако, есть риск, что это не встретит одобрения у целевой аудитории, ведь они скажут, что «мы на эти вопросы повлиять не можем» :(.

Например, вот, что удивило

3-4 — когда пора вводить в проект аналитика, нужен ли аналитик на небольших проектах и как закрывать активности этой роли если его нет
и
7-9 — зачем клиенту и команде аналитик. когда и как продать.
Очень мало и достаточно низкий приоритет вопросов, связанных с аналитиком.
А ведь по сути, это чуть ли не единственная профессия, в профессиональные навыки которого должно входить определение (и даже ограничение, от слова «границы») того, ЧТО нужно сделать, того, что потом оценивать PМ-ам и «продавать» команде:
— Определение особенностей и целей бизнеса клиента, выявление реальных потребностей, которые должны быть удовлетворены, благодаря продукту, который мы для них делаем (знаем, что и зачем делаем — делаем сознательнее и заинтересованнее);
— Определение бизнес-среды заказчика и условий, которые диктуют те или иные deadline-ы (Так узнаем, что именно важно для клиента на разных этапах, т.е. критерии, наиболее ценные для него, влияющие на его удовлетворенность, понимаем, ПОЧЕМУ он «продавливает» сроки и пр. Т.о. сознательнее строим свою работу, не отвлекаемся на неважные в данный момент детали)
— Определение видения и роадмапа развития продукта клиента; партнеров и поставщиков, подрядчиков клиента в том направлении его бизнеса, которому способствует продукт (так мы понимаем, какой должны быть архитектура продукта и понимаем, как она может развиваться. Не говоря уже об идентификации рисков.)
— Сбор и анализ данных о результате delivery продукта (или его части, scope-а проекта)

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

Да, конечно, держать такого аналитика в штате может показаться дорого. Ведь это скорее расходы pre-sale и вряд ли он будет billable. В таком случае нужно, чтобы sales или РМ, или Delivery/Account manager или CEO этим занимались. Поэтому и хотелось бы больше подобных «пинков» с конференций.

Я вижу одну глобальную проблему в ИТ компаниях: отсутствие эффективности на всех уровнях!
Почему? Да потому что нет заинтересованности в этой эффективности и нету мотивации ее поднимать!
А что есть вместо этого: есть «ставка», когда зарплату тебе платят независимо от того, сколько рабочих часов в день ты лайкаешь котиков. Есть бюрократия, которой стараются прикрыть неэффективность на каждом уровне. Отчеты заполнены — значит задница прикрыта. Есть безответственность: никто в ИТ компании не боится быть уволенным (ну кроме уборщиц).
Что в результате? А в результате получаем ту самую «галеру»: где важен процесс гребли, а не результат!
Ситуация настолько запущенная, что даже руководство не берется с ней бороться, а предпочитает искать возможности заработать, работая именно так. Продавая «процесс гребли» и всячески снимая с себя ответственность за результат. Не удивительно что так сложно найти клиентов, которые готовы платить каждый месяц за «мы работаем», а не за «мы сделали».
На самом же деле у ИТ компаний есть огромные резервы производительности! Может ли каждый сотрудник работать эффективнее вдвое? Может! Но только при условии что эффективность — это не число отсиженных часов или закрытых сторипоинтов. А именно достижение конечной цели, которую все четко представляют. И при условии что у человека есть личная мотивация достичь этой цели как можно быстрее.
Я думаю что это возможно только если разделять заинтересованность, прибыль и риски. Кто заинтересован в результате больше всех? Очевидно — заказчик! Он платит деньги, он устанавливает цель, он получит прибыль и он рискует ее не получить. А вот подрядчик сейчас как-бы оппонирует заказчику: его интерес это «развести» заказчика на бабки не разделяя риски. И уже на этом этапе цепочка заинтересованности разрывается: у ИТ компании и заказчика разные цели!
Что если бы было иначе? Если бы все участники проекта (заказчик, сейлзы, менеджмент, девелоперы, тестировщики) зависели от результата? Разделяли возможную прибыль и риски?
1) Нет смысла занижать эстимейты — опоздание ударит по всем.
2) Нет смысла экономить на качестве — проблемы придется чинить за свой счет.
3) Нет смысла терпеть в команде неэффективных людей — они отвалятся сами как только поймут что за «видимость работы» никто им не заплатит.
4) Менеджеру есть смысл не требовать отчеты, а искать способы оградить команду от бюрократии.
5) Есть смысл эффективно распределять задачи: синьор возьмет самые сложные а рутина пойдет джунам.
6) Есть смысл искать лучшие способы решить задачу быстрее, выбирая для этого нужные инструменты и библиотеки.
7) Есть смысл не делать глупой работы: проще объяснить клиенту что на поддержку IE лучше не тратить времени.
8) Девелоперу есть смысл работать тогда, когда он наиболее эффективен и отдыхать когда устал.
9) Есть смысл работать как удобнее — например из дома или из коверкинга.
10) Нет смысла «убивать» время лайкая котиков — лучше сделать быстрее и быть свободным.
11) Есть смысл повышать свою квалификацию — так ты можешь делать быстрее и зарабатывать больше.
Понятно, что построить такой рабочий процесс намного сложнее, чем просто «отсиживать в офисе». «Мерилом работы считают усталость» — это из совка. Но в условиях экономики знаний рано или поздно вознаграждение должно быть именно за результат, а не за потраченное время или приложенные усилия. Это стимулирует постоянно искать лучшие решения, а не «копать от забора до обеда».

Ох, как же вы правы.
Больше всего расстраивает как раз уровень проблемы.
Когда мотивировать приходится топ-менеджеров, а не «рядовых» сотрудников.

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

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

Ну это логично: если человек сейчас стабильно получает 2К без всяких рисков и может при увольнении найти себе другую работу на те же деньги — то ему нет смысла напрягаться. С другой стороны контора продает его за 4К+ и ей то же нет смысла ничего менять. До тех пор, пока нужда не заставит.
С одной стороны ИТ компании хотят наращивать прибыль, а с другой девелоперов, которых можно выгодно перепродавать, ограниченное количество. Клиентам нельзя поднимать рейт до бесконечности да и новых найти не так просто. А значит резервы для количественного роста скоро подойдут к концу.
Уже сейчас «галеры» упираются в «стеклянный потолок»: работодатели не могут платить специалистам много, а «прокачанные» архитекты не могут найти себе работы с адекватной зарплатой. Нет смысла самообучаться до супер-синьора: никто не заплатит столько в Украине.
Выходит нужен рост качественный: зарабатывать больше с теми-же людьми. И тут я вижу большой резерв неиспользованной производительности. Да — придется платит больше, но ведь и работы будет сделано больше. Нужно искать более дорогие проекты, нужно брать на себя риски и решать проблемы заказчика «под ключ». И нужно делиться прибылью от проекта с девелоперами. Пускай даже поначалу будет ставка + премии чем просто тупо ставка.

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

Думаю, да. Вот это парень (www.yegor256.com) интересные вещи толкает.

Егорка, он еще в дныэрию не свалил ?

Не знаю (я уверен, что нет, но лучше его спросить). Да и зачем это ему?

ru.yegor256.com/...​istory-of-separatism.html
Еот такие статейки он пишет, а вот зачем это ему — это уже другой вопрос.

Мало того что просто толкает, он вполне (как сам утверждает конечно же) успешно руководит компанией которая платит исключительно за результаты (оформленные в виде пулл реквестов).

На предидущей работе была попытка...
На счет успешности скажу так — 50 / 50.

А как мотивировать этих топ-менеджеров?

а никак. У них всё норм.
Если что, они просто вовремя сдёрнут с тонущего корабля, назначив крайних.

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

прим: потом я узнал, что через пол-года после моего ухода та контора начала плавно сдуваться, пошли задержки з\п, ну потом начался вообще ахтунг. Но вроде как-то выжила.
А всё к тому шло.

___
Какое сейчас самое модное слово в вакансиях?
Foool стэк.
Улавливаете, наши мыслители «идеального рабочего процесса» (ТМ) совершили «великое закрытие» — нахрен то разделение труда и специализация. В пень конвейер Форда.
Универсальный ж*почас — наше всё.

Какое сейчас самое модное слово в вакансиях?
Foool стэк.

и ещё софт-скилл,
т.е. требуются мягкие хомяки широкого профиля, а не сильные специалисты.

и ещё a positive and resilient mindset, stress tolerance, ability to multitask
прямо из тела вакансий взято мной

Тут в Германии все топы в доле акциями. Ну и потом годовой бонус... Оличная мотивация по моему. Как в Украине всем известно. Так же как и с фондовой биржей, когда компании просто принадлежат одному или нескольким людям. Смотрим на эппл — видим сколько акционеров с какими долями. Разница колоссальна.

разница в подходах к организации разработки — принципиальная.
потому и уезжают отсюда.

Все эти проблемы не редко и у самого кастомера. Ну и часто бюрократия тоже у кастомера ппц бывает, я как-то месяц ждал креды на сорцы!Месяц Карл!

Это точно! Помню как мы несколько месяцев фиксили ворнинги решарпера и стаилкопа в уже готовом проекте. Просто потому что фантазия у тамошнего менеджера уже иссякла, а что-то делать надо что бы бюджет-то осваивать. А до этого полгода адаптировали сайт к разрешению 1024 и IE. Потому что если проект успешно закончен: то тамошнему менеджеру скажут спасибо — и уволят. А так у всех есть тупая работа, а денежки капают.
Но справедливости ради надо сказать что это было до кризиса. Так сказать в «жирные годы», когда потратить лишний лимон на ИТ никто не скупился. Сомневаюсь что сейчас много осталось таких компаний, которые готовы платить за красивые «похороны мертвой лошади».
Наоборот: в погоне на экономией многие крупные клиенты отказываются от услуг посредников — «бодишопов» и нанимают толковых специалистов к себе напрямую.
Поэтому и пишу что украинские «галеры» или будут медленно тонуть , или поменяют свой халтурный подход к заказчикам.

Напишу со стороны немотивированного разработчика. Во всех аутсорсных компаниях, где работал, я делал ровно столько работы, сколько достаточно для того, что бы мне не предъявляли претензий. Почти всегда был демотивирован следующими вещами:
— плохая или ужасная кодовая база
— никто не следит за техническим долгом
— другие разработчики работают неэффективно и все норм, смысл мне стараться, если и так прокатит
— часто у менеджеров проекта было мнение «делаем даже всякие идиотские и бессмысленные вещи пока платят»
— крайне не радовало, что платят за просиженные часы, а у меня работа идет нелинейно, например задача планировалась по срокам на неделю, я сделал свою часть за 3 дня, еще 2 дня сидел на рабочем месте в рефлексии о том, что было бы прекрасно встать и свалить по личным делам на эти 2 дня без потери в деньгах
— поднадоело ходить в офис, так как внезапно осознал, что сидит десяток человек, в наушниках, и все равно общается в слеке или скайпе, какой то сюр.
— в офисе рабочее место не очень. Я дома привык к своим двум 4к мониторам, к мощному хакинтошу и клевому стулу от которого не болит спина. Все это стоило ~ одну мою месячную зп. Просить такое на работу не было смысла так как потом бы пол офиса попросило такое же рабочее место.
— зп так себе, чуть выше среднего по рынку, но средняя по рынку и есть так себе.

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

Условия: договариваюсь работать приблизительно 20-40 часов в неделю (как работа пойдет) без учета времени, заказчик оценивает все ли идет хорошо по тому результату который я предоставляю, пришлось немного поговорить и объяснить что работа программиста нелинейна. И вообщем то платит всегда за месяц (40ч в неделю), даже если реально я работал по часам где то 60%. Все таки ему важно получить результат и особо неважно за сколько точно времени он был сделан. У меня есть интерес сделать задачи быстрее и заниматься своими делами. А еще приятно слушать в свой адрес какой ты эксперт и «awesome man», когда пилишь все быстро или если что то не так, объясняешь что происходит и почему мы тормозим и какие действия заказчику нужно сделать что бы все порешать. Да и вообще приятно когда тебя ценят в продуктовой компании за твои предложения и решения. В таком случае проект воспринимается как то ближе чем обычно и есть настроение его улучшать.

История: у заказчика мелкий бизнес в США, мне дали полный доступ к проду, админкам, отчетности и т.д. я глянут на отчеты по прибыли и расходам и так как у заказчика бюджет на мою работу был на определенное количество месяцев, то я прикинул какой процент от прибыли идет на оплату моей работы. Немного подумав как можно сократить расходы на aws, предложил эту идею заказчику. В итоге, запилив это получил прост так премию и бюджет на свою работу на еще несколько месяцев в дополнение к оговоренному сроку, так как у заказчика появились свободные деньги. Короче, такое приятно и повышает мотивацию. И вообще, понимание откуда приходят и получаются деньги на твою работу открывает глаза и позволяет оценивать пользу от своей части работы на общий доход. А если предложенные мной идеи прям сильно начинают влиять на доход, это повод поговорить о том, что как бы неплохо бы должность новую или в кофаундеры записывать :)

Вот неужели трудно сделать нормальную инфографику? Туда бы свою рекламу бы и поставили.

sales продает дешевле, затем PM оценивает, — дуже дивно, що спочатку сейлз продає, а потім проект оцінюють 0_о «Цікавий» підхід

Ну, клиент вьёт верёвки из сейлзов, с другой стороны СЕО давит, чтобы проект начался, а людей уже как-то там наберём.

У нас есть люди, которые потянут писать для Magento клиенту?
Нет. Один пишет на питоне, два джависта, два .NET, 1 iOS, 1 Android.
Скажем клиенту , что да , сэр, люди есть. Главное медведя поймать — а там как-то запинаем.

неправда, це поширений стереотип не більше :) або ж повторюсь — релевантне лише для починаючих компаній/фрілансерів. Компанія, яка вже певний час на ринку і має певну репутацію, так не продає :) Ну і такий стек "

Один пишет на питоне, два джависта, два .NET, 1 iOS, 1 Android
" в рамках однієї компанії скоріше зустрінеш в індусів, які можуть все :)
" в рамках однієї компанії скоріше зустрінеш в індусів, які можуть все :)
• Общий опыт работы по специальности: не менее 1 года;

• Обязателен опыт работы в команде;
• Большой плюс: наличие портфолио;
• Плюс: знание других языков программирования, кроме Objective C / Swift и других областей (front-end, back-end).
...
...
...

Намёк на то, что все занимаются всем.

" в рамках однієї компанії скоріше зустрінеш в індусів, які можуть все :)

то може бути купа iндусiв пiд єдиним акаунтом

На самом деле, это стратегия «просунуть ногу в дверь». Когда клиент на крючке, задача менеджмента и салесов разводить его на доролнительные деньги.

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

Ну тут успешность компании определяетс возможностью чувствовать правильный момент.

А разве это секрет, что менеджеры по продаже продают клиенту любые хотелки за сколь-угодно малую сумму? Для них важно заключить контракт, и лучше получить меньшую комиссию, чем не получить ничего. А как реализовать все обещанное за указанную сумму и срок — это уже проблемы программистов.

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

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

Бла, бла, бла, покупайте наших слонов ещё больше бла.

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