Skipp существует два года, наши кейсы можно посмотреть на сайте skipp.dev.
Спасибо вам, все пункты по делу, на самом деле.
1) Всё так. Неправильное планирование, выражаясь языком теории, идёт тут как ограничение парадигмы, когда менеджеры строят процессы исходя из фиксированных ресурсов в штате вместо того, чтобы подойди к вопросу открыто и нанимать специалистов под каждую задачу. Например, в начале прототипирования проекта у дизайнеров вал работы, а в конце - ее почти нет, но никто не будет из-за этого увольнять человека из штата. Поэтому парадигма традиционного подхода в разработке и найме и будет этим самым узким местом системы.
2) Очень сложно, но возможно. Посмотрите вокруг – всё больше проектных менеджеров вырастают из PM-ов и разбираются и в метриках, и в разработке, и методологиях управления. Скоро это будет универсальным набором знаний для любого проекта, во всяком случае мы верим, что это наиболее выигрышная комбинация по скиллам у людей будущего. Что же касается настоящего, то наши продакты попадают на проекты исходя из отрасли и специализации. Если нужен проект в сфере интернета вещей, то мы привлекаем специализированного продакта именно с таким опытом.
3) Ну тут без лирики. Просто заранее видим кризисную ситуацию и быстро подтягиваем доп ресурс, "донанимаем" ещё одного человека на бэкэнд или привлекаем еще одного тестировщика.
Штатные команды будут закрывать в себе ценную для бизнеса экспертизу, сохранение и обслуживание которой внутри компании обосновано. Все остальные задачи дешевле, быстрее и спокойнее делать с помощью распределённых команд.
Спасибо за комментарии. Понимаем ваш опыт. Готовим материал об участии разработчиков в таких проектах. Есть много интересных тем для обсуждения)
Skipp существует уже два года. Наши кейсы можно найти на сайте skipp.dev