25.04.2022 20:48:32 UTC+07:00
- Есть способ выяснить под какой грейд подходит разработчик? Как уточнить это не отправляя его на собеседование?
- Есть способ выяснить под какой грейд подходит разработчик? Как уточнить это не отправляя его на собеседование?
- Есть два подхода. Первый, когда вы выходите на крупного заказчика с проектом, которому нужны постоянно разработчики, и ищете кадры под его запросы. Второй, когда вы анализируете рынок и его потребности, а после набираете себе на бенч. Во втором случае, нужно обязательно учитывать, что аутстаф это всегда постоплата, в лучшем случае это 45 дней, а каждому нанятому нужно будет платить з.п. и эти деньги должны быть в кармане, иначе можно попасть в неудобную ситуацию. Лучше сажать на бенч, когда у вас уже есть потенциальные проекты, так более безопасно.
- Какие важные нюансы в заключении договора с заказчиком вы можете выделить?
- Самая важная составляющая договора это оплата. У нас был один кейс когда внесли предоплату 50%, но чаще всего крупные заказчики это значит постоплата, а некоторые банки сейчас пришли к модели оплаты раз в квартал. Если говорить по опыту, постоплата 15 календарных дней - это уже хорошо, учитывая что подписание акта это ещё 15 календарных дней.
Еще нужно сказать, что обязательно диверсифицировать аутстаф. Потому что нехорошо если 15-20 человек работают на одном проекте, с непрогнозируемой загрузкой или с непрогнозируемым выводом. В договоре обязательно прописываем сроки входа и выхода. Если договор заканчивается по инициативе заказчика, чтобы был запас минимум две недели, если мы говорим об 1-2 разработчиках. Должна быть прописана загрузка, мы работаем по фултайму + T&M. Важно чтобы были зеркальные условия для обеих сторон.
- Если с заказчиком начинаются какие-то сложности, допустим с оплатой или проект не устраивает, то как вы посоветуете решать такие проблемы? Расскажите о вашем опыте
- Все зависит от ситуации конечно, по большей части мы стараемся решать всё мирно, не прибегая к условиям договора. Если мы видим, что в будущем клиент может нам предложить ещё контракты, то мы можем уйти, предварительно обсудив компромиссы, чтобы оставаться в хороших отношениях. Поругаться всегда можно успеть, но в бизнесе злоупотреблять таким не стоит.
Сталкивались еще с тем, что когда работаешь с интегратором, то риски возрастают. Из-за того, что когда управление со стороны интегратора, а заказчик пытается влезть и получается непонятно кого слушать. Столкнувшись этой с проблемой мы договорились, что будет один канал постановки задач от РМ. Проработали две недели, и снова со стороны заказчика появляется РМ и ставит задачи. Итог - мы попрощались, но полюбовно даже не соблюдая срока в 10 дней. Я лично договорился, сдали задачи, которые были, нашли другого партнера в этот проект.
- Есть два подхода. Первый, когда вы выходите на крупного заказчика с проектом, которому нужны постоянно разработчики, и ищете кадры под его запросы. Второй, когда вы анализируете рынок и его потребности, а после набираете себе на бенч. Во втором случае, нужно обязательно учитывать, что аутстаф это всегда постоплата, в лучшем случае это 45 дней, а каждому нанятому нужно будет платить з.п. и эти деньги должны быть в кармане, иначе можно попасть в неудобную ситуацию. Лучше сажать на бенч, когда у вас уже есть потенциальные проекты, так более безопасно.
- Какие важные нюансы в заключении договора с заказчиком вы можете выделить?
- Самая важная составляющая договора это оплата. У нас был один кейс когда внесли предоплату 50%, но чаще всего крупные заказчики это значит постоплата, а некоторые банки сейчас пришли к модели оплаты раз в квартал. Если говорить по опыту, постоплата 15 календарных дней - это уже хорошо, учитывая что подписание акта это ещё 15 календарных дней.
Еще нужно сказать, что обязательно диверсифицировать аутстаф. Потому что нехорошо если 15-20 человек работают на одном проекте, с непрогнозируемой загрузкой или с непрогнозируемым выводом. В договоре обязательно прописываем сроки входа и выхода. Если договор заканчивается по инициативе заказчика, чтобы был запас минимум две недели, если мы говорим об 1-2 разработчиках. Должна быть прописана загрузка, мы работаем по фултайму + T&M. Важно чтобы были зеркальные условия для обеих сторон.
- Если с заказчиком начинаются какие-то сложности, допустим с оплатой или проект не устраивает, то как вы посоветуете решать такие проблемы? Расскажите о вашем опыте
- Все зависит от ситуации конечно, по большей части мы стараемся решать всё мирно, не прибегая к условиям договора. Если мы видим, что в будущем клиент может нам предложить ещё контракты, то мы можем уйти, предварительно обсудив компромиссы, чтобы оставаться в хороших отношениях. Поругаться всегда можно успеть, но в бизнесе злоупотреблять таким не стоит.
Сталкивались еще с тем, что когда работаешь с интегратором, то риски возрастают. Из-за того, что когда управление со стороны интегратора, а заказчик пытается влезть и получается непонятно кого слушать. Столкнувшись этой с проблемой мы договорились, что будет один канал постановки задач от РМ. Проработали две недели, и снова со стороны заказчика появляется РМ и ставит задачи. Итог - мы попрощались, но полюбовно даже не соблюдая срока в 10 дней. Я лично договорился, сдали задачи, которые были, нашли другого партнера в этот проект.