Недавно прочитал пост о том, как коллега-бизнесмен развивает своё пельменное производство. Из всего написанного меня особенно зацепила мысль: для того чтобы создавать конкурентный продукт, нужно покупать дешёвое мясо, ещё и быстро замораживать, чтобы пельмень не потерял вес.
И вот что подумалось: все мы покупаем продукты. Все знаем, что хороший кусок мяса стоит около 500 руб/кг, при этом пельмени за 700 руб/кг — для нас дорого. А когда мы покупаем пельмени за 200 руб/кг — ругаемся, что они невкусные.
Как так?
Ведь логично, что, если кто-то сделал качественные пельмени из вкусных ингредиентов (мяса, овощей, муки, специй), результирующий продукт будет стоить больше стоимости компонентов. Не забываем прибавить расходы бизнеса на зарплату персоналу, коммуналку, оборудование и его амортизацию, налоги, форс-мажоры.
Но даже в этой очевидной ситуации мы упорно ищем пельмени «дешевле здравого смысла».
📌 При чём тут IT-проекты?
Я со своей командой занимаюсь заказной разработкой ПО, и здесь история ещё более нелогичная.
- Есть перегретый рынок труда, на котором компетентные разработчики-мидлы хотят получать «от 200 к на руки».
- Есть накладные, расходы, налоги.
- Добавим к этому желание заказчика получить оценку проекта на старте — порой, при туманных требованиях — и уложиться в стремительно приближающийся дедлайн.
Для нас это значит, что в ходе проекта будет недостаточно просто соблюдать стандарты качества и подробного Code Style. Придётся ускорить работу. И привлекать уже не мидлов, а сеньоров.
После того как заказчик получает несколько предложений с рынка, он выбирает либо самое дешёвое, либо чуть дороже минимального.
Что в итоге: вероятность сдачи проекта в срок при реализации всех требований практически нулевая.
📌«Рецепты», которыми злоупотребляют команды разработки
Вот несколько рецептов современного «успешного» аутсорсинга, который часто используют в IT-среде (и в пельменях ;)
Сильный HR, который умеет быстро набирать джунов и быстро прокачивать их для прохождения интервью уровня мидла у заказчиков.
В пельменном производстве продавцы мяса закачивают водно-солевой раствор, чтобы увеличить вес.
Опытный руководитель проекта, который убедительно описывает причины, почему тот или иной функционал не сделан в срок по причинам, взятым из воздуха по вине заказчика.
Популярные аргументы: отсутствие требований, не предоставлен доступ к инфраструктуре на стороне заказчика, задержка с согласованием контракта.
Тут аналогов для пельменолепов нет.
Толковый тимлид, который «вертится ужом», разбивая проект на простейшие компоненты, чтобы почти-джуны могли выполнять задачи мидлового уровня.
В пельменях это технолог, который составляет технологические карты и измеряет производственные нормы каждого этапа и начальник производства, балансирующий между невышедшим из-за похмелья резчиком овощей и неисправной холодильной установкой, в которой кто-то повредил трубки с хладагентом.
Стрессоустойчивый QA, приводящий Франкенштейна в чувство в последние дни перед сдачей проекта.
Не знаю, как это работает для пельменей — их уж слепили как слепили.
Интересное наблюдение: когда у клиента есть свои разработчики, и он считает стоимость проекта «внутри» по тем же требованиям, что выставляет наружу, она будет в разы выше оценки, предоставляемой большинством подрядчиков.
Это как если вы устали есть невкусные пельмени, купили сами мясо, вечерком всей семьёй лепите до полуночи, а потом едите и нахваливаете, забыв, что потратили в 5 раз больше, даже привлекая бесплатную рабочую силу детей и мужа.
Мораль здесь такова: хотите «вкусный» результат — подумайте о том, из чего он состоит, и здраво оцените стоимость.
📌Чек-лист по выбору «пельменолепов» в IT
Чтобы помочь вам более реалистично посмотреть на вопрос сроков и стоимости разработки ПО, составил небольшой чек-лист для заказчика услуг IT-компаний.
В нём — то, на что стоит обращать внимание в первую очередь, получив оценку проекта от потенциального подрядчика.
1. Подробная декомпозиция работ
Требуйте максимально подробную декомпозицию работ. Если её нет, потенциальный исполнитель невнимательно читал ваше ТЗ.
Полезно пройтись по всем пунктам и получить объяснение, почему именно такая оценка получилась.
2. Честная оценка рисков
Спрашивайте, что может пойти не так. В производстве ПО всегда много подводных камней и рисков. Добросовестный исполнитель всегда их держит в голове и готов рассказать о них.
Если нет, смело ищите дальше.
3. Возможность регулярно проверять полезный результат
Просите разбивать работу на этапы, каждый из которых оканчивается результатом, который легко проверить, даже не имея глубоких технических знаний.
Примеры плохого разбиения на этапы: «разработка архитектуры» и «реализация функционала».
Хорошие примеры: «реализация личного кабинета менеджера» и «реализация бизнес-процесса заказа продукции».
4. Готовность выполнить тестовое задание
Если работаете по модели Time&Material, не оценивайте специалистов только по собеседованию.
Дайте небольшую практическую задачу и помните, что второй раз одну и ту же задачу давать нельзя: HR со стороны исполнителя будет натаскивать разработчиков на типовые задачи. А чем сложнее проект, тем более важно подобрать исполнителей, готовых находить нелинейные решения.
Поддержите пост реакциями, если информация оказалась полезна. Так я пойму, стоит ли развивать тему подбора IT-подрядчиков дальше.
Комментарий недоступен