Риски такие: Краткосрочное привлечение переводчиком китайского на русский человека, который умеет и всю жизнь занимался только переводом с немецкого на русский имеет большой риск не получить ничего, кроме потраченных усилий других членов команды, что в итоге ещё сильнее затормозит процесс и КПД будет в такой синергии отрицательный. На сколько такое agile перемещение поможет проекту на время отпуска или болезни переводчика с китайского? Ответ лежит в скорости переобучения имеющегося заменителя, другими словами онбординг. Если отбросить красивую теорию и обратиться к опыту полевой практики такие вопросы основные на проекте и опытный менеджер должен подумать три раза, прежде, чем приводить замену, да ещё и краткосрочную. Техпис может быть быстро релоцирован, но это низкоквалифицированный труд. Специалистов высокой экспертизы - системных аналитиков, разработчиков, DBA, автотестеров анбордить за "полдня" не получится. Это в большинстве случаев очень долгий и сложный процесс, особенно на старых легаси, где мало/много документации, сильно закостыленый код, который знает 2 человека на планете и пр.
При этом, если разобрать, почему техписа просто релоцировать, а Ява разработчика нет.. Потому, что техпис это печатная машинка, работающая на сильно унифицированном и хорошо понятном уровне абстракции (он описывает то, что ему дадут. Сам не анализирует глубоко). Agile биржа и почие карусельные конвейеры будут работать только в случае крайне точной унификации всех процессов - 1. Внедрена единая технологическая платформа, в которой все компоненты всей организации имеют одинаковые версии, релизы и тд, 2. Имеется по одно типу сверстанная документация с тотально подробным, но лаконичным описанием всех компонент (документация обогащается в автоматическом режиме вместе с разработкой нового ф-ла), 3. В организации внедрены подходы т-шейп, демо дни, внутренние стажировки и формируются команды/стримы/системы побратимы, являющиеся друг для друга пулом срочной помощи (специализация на системах друг друга), 4. Тотальное документирование всего кода, культура документирования на высоком уровне и ей уделяется отдельное внимание, вся документация сквозная от строчки в инструкции до строчки кода, которую инструкция описывает, 5. Внедрение реактивных практик кодирования, 6...7...что-то ещё
Спасибо за развёрнутый комментарий. Мы с вами, в основном, согласны — в настоящее невозможно чётко провести границы использования создаваемого сервиса. И да, это для больших организаций с отстроенным технологическим процессом. 1. Одним из upside сервиса будет дополнительный стимул к соблюдению правил разработки; 2. В одношении senior-ов. В Яндексе есть внутренний сервис .. смешно называется, типа: "МарьВанована". Туда можно написать любой запрос. Т.е. есть группа высококвалифицированных сотруников, которые вылопняют ультракраткосрочные задачи. Поэтому можно предполагать, что и для senior-ов найдутся задачи типа консалтинга.
Риски такие:
Краткосрочное привлечение переводчиком китайского на русский человека, который умеет и всю жизнь занимался только переводом с немецкого на русский имеет большой риск не получить ничего, кроме потраченных усилий других членов команды, что в итоге ещё сильнее затормозит процесс и КПД будет в такой синергии отрицательный. На сколько такое agile перемещение поможет проекту на время отпуска или болезни переводчика с китайского? Ответ лежит в скорости переобучения имеющегося заменителя, другими словами онбординг. Если отбросить красивую теорию и обратиться к опыту полевой практики такие вопросы основные на проекте и опытный менеджер должен подумать три раза, прежде, чем приводить замену, да ещё и краткосрочную. Техпис может быть быстро релоцирован, но это низкоквалифицированный труд. Специалистов высокой экспертизы - системных аналитиков, разработчиков, DBA, автотестеров анбордить за "полдня" не получится. Это в большинстве случаев очень долгий и сложный процесс, особенно на старых легаси, где мало/много документации, сильно закостыленый код, который знает 2 человека на планете и пр.
При этом, если разобрать, почему техписа просто релоцировать, а Ява разработчика нет.. Потому, что техпис это печатная машинка, работающая на сильно унифицированном и хорошо понятном уровне абстракции (он описывает то, что ему дадут. Сам не анализирует глубоко).
Agile биржа и почие карусельные конвейеры будут работать только в случае крайне точной унификации всех процессов - 1. Внедрена единая технологическая платформа, в которой все компоненты всей организации имеют одинаковые версии, релизы и тд, 2. Имеется по одно типу сверстанная документация с тотально подробным, но лаконичным описанием всех компонент (документация обогащается в автоматическом режиме вместе с разработкой нового ф-ла), 3. В организации внедрены подходы т-шейп, демо дни, внутренние стажировки и формируются команды/стримы/системы побратимы, являющиеся друг для друга пулом срочной помощи (специализация на системах друг друга), 4. Тотальное документирование всего кода, культура документирования на высоком уровне и ей уделяется отдельное внимание, вся документация сквозная от строчки в инструкции до строчки кода, которую инструкция описывает, 5. Внедрение реактивных практик кодирования, 6...7...что-то ещё
Спасибо за развёрнутый комментарий. Мы с вами, в основном, согласны — в настоящее невозможно чётко провести границы использования создаваемого сервиса. И да, это для больших организаций с отстроенным технологическим процессом.
1. Одним из upside сервиса будет дополнительный стимул к соблюдению правил разработки;
2. В одношении senior-ов. В Яндексе есть внутренний сервис .. смешно называется, типа: "МарьВанована". Туда можно написать любой запрос. Т.е. есть группа высококвалифицированных сотруников, которые вылопняют ультракраткосрочные задачи. Поэтому можно предполагать, что и для senior-ов найдутся задачи типа консалтинга.