И, в-третьих, штатным сотрудникам участие во временной команде позволяет повысить квалификацию, получить новые профессиональные навыки, например, когда специалист хочет сменить профиль, но не уверен в своих силах. Работа в таком формате даёт возможность попробовать решить задачу или более высокого грейда, или нетипичную для его текущего профиля, или вообще из другого направления. В работе над коротким проектом специалист сможет убедиться в том, что он:
Риски такие:
Краткосрочное привлечение переводчиком китайского на русский человека, который умеет и всю жизнь занимался только переводом с немецкого на русский имеет большой риск не получить ничего, кроме потраченных усилий других членов команды, что в итоге ещё сильнее затормозит процесс и КПД будет в такой синергии отрицательный. На сколько такое agile перемещение поможет проекту на время отпуска или болезни переводчика с китайского? Ответ лежит в скорости переобучения имеющегося заменителя, другими словами онбординг. Если отбросить красивую теорию и обратиться к опыту полевой практики такие вопросы основные на проекте и опытный менеджер должен подумать три раза, прежде, чем приводить замену, да ещё и краткосрочную. Техпис может быть быстро релоцирован, но это низкоквалифицированный труд. Специалистов высокой экспертизы - системных аналитиков, разработчиков, DBA, автотестеров анбордить за "полдня" не получится. Это в большинстве случаев очень долгий и сложный процесс, особенно на старых легаси, где мало/много документации, сильно закостыленый код, который знает 2 человека на планете и пр.
При этом, если разобрать, почему техписа просто релоцировать, а Ява разработчика нет.. Потому, что техпис это печатная машинка, работающая на сильно унифицированном и хорошо понятном уровне абстракции (он описывает то, что ему дадут. Сам не анализирует глубоко).
Agile биржа и почие карусельные конвейеры будут работать только в случае крайне точной унификации всех процессов - 1. Внедрена единая технологическая платформа, в которой все компоненты всей организации имеют одинаковые версии, релизы и тд, 2. Имеется по одно типу сверстанная документация с тотально подробным, но лаконичным описанием всех компонент (документация обогащается в автоматическом режиме вместе с разработкой нового ф-ла), 3. В организации внедрены подходы т-шейп, демо дни, внутренние стажировки и формируются команды/стримы/системы побратимы, являющиеся друг для друга пулом срочной помощи (специализация на системах друг друга), 4. Тотальное документирование всего кода, культура документирования на высоком уровне и ей уделяется отдельное внимание, вся документация сквозная от строчки в инструкции до строчки кода, которую инструкция описывает, 5. Внедрение реактивных практик кодирования, 6...7...что-то ещё
Спасибо за развёрнутый комментарий. Мы с вами, в основном, согласны — в настоящее невозможно чётко провести границы использования создаваемого сервиса. И да, это для больших организаций с отстроенным технологическим процессом.
1. Одним из upside сервиса будет дополнительный стимул к соблюдению правил разработки;
2. В одношении senior-ов. В Яндексе есть внутренний сервис .. смешно называется, типа: "МарьВанована". Туда можно написать любой запрос. Т.е. есть группа высококвалифицированных сотруников, которые вылопняют ультракраткосрочные задачи. Поэтому можно предполагать, что и для senior-ов найдутся задачи типа консалтинга.
Риски - сплошь и рядом.
Опытные фрилансеры уровня Senior - абсолютно не ваша аудитория по той причине что вы им не нужны, т.к они загружены задачами, проектами вперед не на один месяц и уровень оплаты достаточно высок.
Ну а Middle / Junior или Junior переходящий в Middle - срыв сроков как минимум либо слив с проекта. К тому же даже если вы на своей стороне реализуете полноценный ЭДО, то у большинства фрилансеров либо желания не будет на коротких итерациях заморачиваться, либо нет ЭЦП и т.д и т.п.
Проводить CastDev никакого смысла нет, достаточно опубликовать на всех фриланс биржах пару,тройку задач одним спринтом с пару итераций и вы поймете какая это боль поймать коннект, потратить время на коммуникацию и т.д , а в процессе может пойти все не так как хотелось бы и зачастую так и случается.
Для крупного холдинга оптимальный выбор это взращивать свою аутстафф команду резерва, а не в виде таск биржи, которую можно делегировать между компаниями.
Спасибо.
В первую очередь, разрабатываемый сервис для внутренних сотрудников, поэтому степень ответственности другая.
Мы пока не можем опубликовать задачи на внешних ресурсах. ИБ!
Для этого и делается MVP — надо проверить гипотезы и выявить риски
Добрый день, Константин! Звучит отлично!
*Какие риски могут препятствовать решению задачи?
- отсутствие обучения HR отдела работе с данным инструментом.
- срок выполнения задачи может увеличиться, если принять во внимание человеческие факторы исполнителей или отсутствие четко сформулированного ТЗ
- формулировать ТЗ тоже должен человек, имеющий квалификацию и навыки коммуникации. А это чаще всего дорогой специалист. Соответственно ему придется ставить большое количество маленьких задач и ещё мучиться с недобросовестными исполнителями и сортировать их.
Поэтому возможно принцип "хочешь сделать хорошо - сделай сам" в данном случае может у многих пересилить.
*Какие ещё направления работы AGILE-биржи возможны?
- как вариант : внутри каждой компании может быть подобная доска со "стикерами с грязной работой" . За выполнение определенного количества таких стикеров полагается премия. Тогда тайна ЗП сохраняется. Мы считаем не стоимость работы, а количество выполненных проектов. А сам постановщик задачи тоже заинтересован в том, чтобы его задачи брали. Он получает рейтинг по количеству взятых у него проектов. Получается внутри компании появляется возможность доп заработка, а у руководителей или менеджеров проектов - свободные руки.
* Какие направления, на ваш взгляд, принесут компании наибольшую пользу и какой функционал нужно реализовывать в первую очередь?
- сортировка задач по компетенциям
- система рейтинга исполнителя и работодателя
- возможность встроить данную фичу в корп портал крупных предприятий и холдингов без слёз
Тимофей, спасибо за ответы.
1. В отношение рисков:
1.1 HR очень хотят. Некоторы из них считают, что текущая загрузка сотрудников не более 90%. По независящим от сотрудников причинам. Перебрасывая задачи из команды в команду, можно полностью загрузить простаивающих, разнообразив их работу
1.2 Мысль про разрастание задачи очень интересная. Нужна процедура увеличения трудоёмкости
1.3 Про ТЗ. Мы в парадигме большой организации с унифицированным технологическим процессом. Поэтому можно формулировать ТЗ типа: "Добавить в АИС взаимодействие ИС "Аудит" на контуре HOTFIX", которое будет понятно и тимлиду, и исполнителю.
2. Мысль про "грязные задачи" очень ценная. Спасибо.
Можно ли порекомендовать T1 улучшить сайт t1.ru?
Он выглядит как-то простецки.
Цвет бирюзово-голубой, шрифты, зазоры.
Все выглядит отталкивающе.
Как-будто заходишь на сайт частной мебельной фабрики в далеком регионе, у которой все очень плохо с оборотом.
Надеюсь не обидел.
На месте руководства серьезно бы вложился в новый, современный UI/UX.