О "болях" работы со студиями со стороны субподрядчика

Обычно пишут посты с позиции студий про трудности работы с заказчиками и наоборот. Наш пост о "болях" работы со студиями с невидимой вам стороны, а именно - взгляд аутсорс-программистов под NDA.

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

А дальше хотим пометить, упреждая возможные вопросы и колкости на тему: да, мы давно на рынке; да, мы делаем сложные проекты; да, у нас есть комплексные маркеры для фильтрации клиентов - просто за несколько лет у нас накопилась именно такая выборка кейсов.

Клиент хочет потестить релиз перед выходными и студия просит сделать его в пятницу утром. Но так или иначе, несмотря на все усилия тестера, можно не заметить в релизе какую-то мелочь. В итоге просьба релиза в пятницу утром, может превратиться в проблему выкатить апдейт в пятницу вечером. В результате, вам с разработчиками предстоят веселые выходные, либо, если проблема не критичная - ждать понедельника c постоянной фоновой мыслью "в релизе проблема".

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

Студия не понимает модель работы и аргументацию цены аутсорс-продакшена в рамках схемы человеко-часы и хочет узнать цену, исходя из позиции "не более такой-то суммы". Далее возникает ситуация, когда аутсорс-продакшен не участвует в процессе пресейла. На оценку приходит условно типовая задача, которая оценивается плюс/минус, а потом в процессе формирования конечной цены, всплывают новые требования и у студии возникает вопрос: вы же сказали не более N, почему теперь прайс вырос. Студия не понимает, что определение цены требует полного пакета требований к проекту заказчика, и без этих подробностей оценка будет либо занижена, либо наоборот - завышена.

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

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

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

Целенаправленно присылают “не наши” баги под видом “наших”. Как правило, git помогает показать, кто реально создал проблему, но в ходе выяснений тратится наше время (которое оплачивать обычно никто не спешит). Имеем ситуацию, когда бесплатно вынуждены фиксить чужие баги за свой счет, то есть по факту хитрый менеджмент таким способом экономит бюджет, но проект уже идет и его нужно завершить

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

Cтудиям: подобного рода "экономия" все равно всплывает, и в итоге ведет только к задержкам в работе, потере качества и испорченным отношениям с подрядчиком.

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

Как правило, задача таких менеджеров - работа в качестве передатчиков хотелок клиента (этакие "почтальоны"). При работе с "почтальоном" вам придется все разжевывать до уровня школы и тратить неимоверно много времени, которое стоит денег, а заказчик "почтальона" в бюджет не закладывал. Иногда срабатывает вариант достучаться до руководства и решить проблемы, но далеко не все пытаются это сделать, а в таком случае рентабельность может падать до нуля.

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

Вывод: фильтруйте клиентов и составляйте четкое ТЗ. В противном случае - куча потерянного времени (читай - денег) и нервов гарантирована.

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

Вывод: бронируйте время, только если оценен фронт работ.