Над первой версией работало 3 Android-разработчика, ими было затрачено примерно 700 часов. Экранов было примерно 20, этого было достаточно чтобы выпустить полноценное приложение, которое не получило негатива от пользователей, что им чего-то не хватает, и далее уже развивать проект в новых версиях.
Не стоит говорить в целом про все компании данного типа. Для каких-то действительно это будет так, к сожалению. Но по каждому тезису могу ответить в рамках нашего опыта:
"после нас хоть потоп" – вероятно это может быть так в компаниях для которых не важна репутация, работают как конвейер, пытаются получать заказы за счёт заниженной стоимости, а не качества. Если же компания с хорошей репутацией как среди разработчиков, так и среди заказчиков, то она будет стараться эту репутацию подтверждать. И мы как раз за развитие проектов, а не сделать и слить побыстрее. Среднее время работы с клиентами более 3 лет. Разработчики понимают, что проект будут развивать они и дальше, или их коллеги, поэтому к качеству кода вопросов нет, и подключение к проекту или передача инхаус не вызывает проблем. Для нас приоритет это долгосрочные отношения с заказчиками, а не разовая реализация проекта.
"не может разбираться так же хорошо в прикладной области" – тут тоже всё зависит от кейса. Если мы рассматриваем какой-то начинающий бизнес, у которого опыт собственный небольшой, а у аутсорс компании есть в кейсах успешные примеры из сферы заказчика, то такое взаимодействие будет полезным для заказчика. В статье про выбор подрядчика мы как раз писали, что стоит обращать внимание на опыт в нужной сфере, так как он не будет лишним. Если говорим про сформированную команду продукта с хорошим опытом именно в продукте, то ничего не мешает объединить этот опыт с опытом команды в разработке, чтобы не тратить время на старте на формирование команды.
"аутсорсеры уходят и уносят экспертизу" – чтобы была возможность развития своих сотрудников нужно чтобы эта экспертиза в компании как-то появилась, в том числе у менеджмента, иначе существует риск создания внутренней некомпетентной команды, где на старте проекта будет стоять джун, который заложит такой фундамент, который в итоге не позволит проекту развиваться качественно. Для кейса, когда заказчик хочет всё-таки потенциально инхаус команду мы работали по следующей схеме: за этап документации и дизайна обеих платформ отвечали полностью мы, при этом у нас были регулярные созвоны с командой заказчика, где мы всё обсуждали; далее на этапе разработки мы сразу в инфраструктуре заказчика настроили проекты, но за разработку Android проекта отвечали мы, а за iOS проект отвечала уже внутренняя команда, которую начали формировать; Android опережал намеренно, чтобы задачи в первую очередь ставились нами, а для iOS обозначались какие-то кейсы, которые требовали дополнительной логики, если они были нужны. Таким образом была сформирована мобайл компетенция в команде заказчика, старт проекта был заложен разработчиками хорошего уровня, чтобы не было проблем с развитием. С наймом во внутренние команды заказчикам также помогаем, чтобы помочь в кейсе, когда у заказчика нет технической экспертизы для этого.
Будет интересно посмотреть на статистику, если кто-то когда-то этим займётся. А пока же хотелось сказать, что не стоит обобщать и говорить, что эти высказывания верны по отношению ко всему аутсорсу. Мы нигде в целом не писали, что это мифы, а обратили внимание, что всё это риски, которые следует учитывать начиная свой проект и выбирая формат работы, и которых можно избежать выбирая подходящую для задач аутсорс команду.
Да, все так. Именно поэтому мы стараемся вовлекать разработчиков на всех этапах проекта. И на всех этапах получаем ценные идеи, которые с радостью передаем заказчикам, а те их очень часто согласовывают в работу. Не всегда разработчик, который на этапе ТЗ и проектирования помогает проведением технического-ревью, будет сам реализовывать задачу, поэтому в течение проекта также все разработчики вовлекаются на планированиях, демо и прочих митингах в бизнесовую часть, чтобы понимать что и для чего они реализовывают и могли предлагать идеи для улучшения проекта
Проблем согласований с заказчиком у нас нет, спасибо) Как нет и проблем недопонимания менеджеров и разработчиков. Про данные инструменты знаем, они применяются на тех задачах, где необходимы, а каждую задачу снабжать бесконечным числом артефактов не стоит. Помним про условие необходимости. И как написано в статье добавлять любые визуальные и информационные артефакты можно, если они помогут в лучшем понимании информации
Приходящие менеджеры с опытом в других айти-проектах обычно, но обычно не настолько глубоко погруженные в тех. часть. У нас плавный онбординг и обучение всему необходимому под контролем более опытного менеджера. Поэтому при найме супер завышенных требований нет, скорее выделяем достаточно времени на обучение внутри, например, той же самой работе с API. Но проблем не возникает
В целом по всем вопросам уже отвечала в комментарии выше, но:
какие запросы куда идут - вообще без разницы, за это отвечает либо лид, либо архитектор, либо тот кто видит целостную картину.
У нас менеджер и видит целостную картину. В зависимости от размера команды появляются новые роли, для которых так или иначе написанное в статье актуально. Можете это воспринимать как текст для разработчика и то, что ему нужно учесть при работе над задачей
Да, конечно, все зависит от компании. И возможно, что где-то этими задачами будет заниматься не один проджект-менеджер, как у нас, а еще будет бизнес-аналитик, системный-аналитик, тимлид, архитектор и другие роли. Хотелось больше подсказать вещи, которые помогают ошибаться меньше, даже если они будут распределены.
Про такое описание API – не всегда мы от команды бэкенда заказчика получаем красивый сваггер на который можно сослаться (как всегда хочется), в итоге иногда приходится выяснять разными доступными способами и запросы, и ответы, и опциональность и прочее. Если есть возможность сослаться на спеку по запросу, то отлично, но это только один пункт из работы по задаче)
В любом случае, кроме примеров, в вашей статье есть дельные соображения, спасибо.
Текст статьи не станет проще и интереснее, если вы будете втыкать мемы через абзац.
Ну это вкусовщина и кому как.
техническое решение известно еще на этапе постановки
Не очень понимаю где тут техническое решение. Удобное предоставление информации по взаимодействию с API и данными это техническое решение? Описание кейсов – это бизнес-логика, которая должна соответствовать поставленным требованиям и те же 0-даты не могут отдаваться на усмотрение разработчика. Разработчики, в моем представлении, не должны придумывать как решать проблему бизнеса, не должны пытаться выяснять требования, они должны решать технические вопросы, писать красивый и качественный код с минимальным числом ошибок и переделок. А для этого следует давать им необходимую информацию. Также описание необходимо и для тестирования, для понимания логики взаимодействия с сервером. Поясню, что мы занимаемся аутсорс разработкой и требования к моменту передачи фичи в разработку уже довольно определены. А наши менеджеры прекрасно разбираются в своей области и часть связанную с проектированием API закрывают самостоятельно или при помощи разработчиков до непосредственного начала выполнения задачи, так как нам важно не быть заблокированными в процессе бэкендом.
В этом плане ваши примеры “хорошо описанных задач” просто ужасны. Ни в одном из примеров не описано, кому вообще нужны эти фичи, в каком контексте и какая польза бизнесу, зато полно сомнительных технических деталей.
Кажется, что разработчикам не особо надо пояснять зачем нужна загрузка данных или для чего нужен неавторизованный стейт экрана. При этом про важность информации для чего фича нужна, если это не очевидно, в тексте статьи написано. Наши разработчики любят предлагать фичи и улучшать пользовательский опыт, но это делается через обсуждения и согласования, а не отдается им на единоличное решение. И задачи из разряда “Сделай экран хорошо” без описания мы не делаем.
Над первой версией работало 3 Android-разработчика, ими было затрачено примерно 700 часов. Экранов было примерно 20, этого было достаточно чтобы выпустить полноценное приложение, которое не получило негатива от пользователей, что им чего-то не хватает, и далее уже развивать проект в новых версиях.
Не стоит говорить в целом про все компании данного типа. Для каких-то действительно это будет так, к сожалению. Но по каждому тезису могу ответить в рамках нашего опыта:
"после нас хоть потоп" – вероятно это может быть так в компаниях для которых не важна репутация, работают как конвейер, пытаются получать заказы за счёт заниженной стоимости, а не качества. Если же компания с хорошей репутацией как среди разработчиков, так и среди заказчиков, то она будет стараться эту репутацию подтверждать. И мы как раз за развитие проектов, а не сделать и слить побыстрее. Среднее время работы с клиентами более 3 лет. Разработчики понимают, что проект будут развивать они и дальше, или их коллеги, поэтому к качеству кода вопросов нет, и подключение к проекту или передача инхаус не вызывает проблем. Для нас приоритет это долгосрочные отношения с заказчиками, а не разовая реализация проекта.
"не может разбираться так же хорошо в прикладной области" – тут тоже всё зависит от кейса. Если мы рассматриваем какой-то начинающий бизнес, у которого опыт собственный небольшой, а у аутсорс компании есть в кейсах успешные примеры из сферы заказчика, то такое взаимодействие будет полезным для заказчика. В статье про выбор подрядчика мы как раз писали, что стоит обращать внимание на опыт в нужной сфере, так как он не будет лишним. Если говорим про сформированную команду продукта с хорошим опытом именно в продукте, то ничего не мешает объединить этот опыт с опытом команды в разработке, чтобы не тратить время на старте на формирование команды.
"аутсорсеры уходят и уносят экспертизу" – чтобы была возможность развития своих сотрудников нужно чтобы эта экспертиза в компании как-то появилась, в том числе у менеджмента, иначе существует риск создания внутренней некомпетентной команды, где на старте проекта будет стоять джун, который заложит такой фундамент, который в итоге не позволит проекту развиваться качественно. Для кейса, когда заказчик хочет всё-таки потенциально инхаус команду мы работали по следующей схеме: за этап документации и дизайна обеих платформ отвечали полностью мы, при этом у нас были регулярные созвоны с командой заказчика, где мы всё обсуждали; далее на этапе разработки мы сразу в инфраструктуре заказчика настроили проекты, но за разработку Android проекта отвечали мы, а за iOS проект отвечала уже внутренняя команда, которую начали формировать; Android опережал намеренно, чтобы задачи в первую очередь ставились нами, а для iOS обозначались какие-то кейсы, которые требовали дополнительной логики, если они были нужны. Таким образом была сформирована мобайл компетенция в команде заказчика, старт проекта был заложен разработчиками хорошего уровня, чтобы не было проблем с развитием. С наймом во внутренние команды заказчикам также помогаем, чтобы помочь в кейсе, когда у заказчика нет технической экспертизы для этого.
Я про статью, не про комментарий) Опыт, конечно, у всех свой и жаль, что для вас он был не в пользу наёмных
Будет интересно посмотреть на статистику, если кто-то когда-то этим займётся. А пока же хотелось сказать, что не стоит обобщать и говорить, что эти высказывания верны по отношению ко всему аутсорсу. Мы нигде в целом не писали, что это мифы, а обратили внимание, что всё это риски, которые следует учитывать начиная свой проект и выбирая формат работы, и которых можно избежать выбирая подходящую для задач аутсорс команду.
Да, все так. Именно поэтому мы стараемся вовлекать разработчиков на всех этапах проекта. И на всех этапах получаем ценные идеи, которые с радостью передаем заказчикам, а те их очень часто согласовывают в работу. Не всегда разработчик, который на этапе ТЗ и проектирования помогает проведением технического-ревью, будет сам реализовывать задачу, поэтому в течение проекта также все разработчики вовлекаются на планированиях, демо и прочих митингах в бизнесовую часть, чтобы понимать что и для чего они реализовывают и могли предлагать идеи для улучшения проекта
Проблем согласований с заказчиком у нас нет, спасибо) Как нет и проблем недопонимания менеджеров и разработчиков. Про данные инструменты знаем, они применяются на тех задачах, где необходимы, а каждую задачу снабжать бесконечным числом артефактов не стоит. Помним про условие необходимости. И как написано в статье добавлять любые визуальные и информационные артефакты можно, если они помогут в лучшем понимании информации
Приходящие менеджеры с опытом в других айти-проектах обычно, но обычно не настолько глубоко погруженные в тех. часть. У нас плавный онбординг и обучение всему необходимому под контролем более опытного менеджера. Поэтому при найме супер завышенных требований нет, скорее выделяем достаточно времени на обучение внутри, например, той же самой работе с API. Но проблем не возникает
В целом по всем вопросам уже отвечала в комментарии выше, но:
У нас менеджер и видит целостную картину. В зависимости от размера команды появляются новые роли, для которых так или иначе написанное в статье актуально. Можете это воспринимать как текст для разработчика и то, что ему нужно учесть при работе над задачей
Да, конечно, все зависит от компании. И возможно, что где-то этими задачами будет заниматься не один проджект-менеджер, как у нас, а еще будет бизнес-аналитик, системный-аналитик, тимлид, архитектор и другие роли. Хотелось больше подсказать вещи, которые помогают ошибаться меньше, даже если они будут распределены.
Про такое описание API – не всегда мы от команды бэкенда заказчика получаем красивый сваггер на который можно сослаться (как всегда хочется), в итоге иногда приходится выяснять разными доступными способами и запросы, и ответы, и опциональность и прочее. Если есть возможность сослаться на спеку по запросу, то отлично, но это только один пункт из работы по задаче)
Надеюсь)
Ну это вкусовщина и кому как.
Не очень понимаю где тут техническое решение. Удобное предоставление информации по взаимодействию с API и данными это техническое решение? Описание кейсов – это бизнес-логика, которая должна соответствовать поставленным требованиям и те же 0-даты не могут отдаваться на усмотрение разработчика. Разработчики, в моем представлении, не должны придумывать как решать проблему бизнеса, не должны пытаться выяснять требования, они должны решать технические вопросы, писать красивый и качественный код с минимальным числом ошибок и переделок. А для этого следует давать им необходимую информацию. Также описание необходимо и для тестирования, для понимания логики взаимодействия с сервером. Поясню, что мы занимаемся аутсорс разработкой и требования к моменту передачи фичи в разработку уже довольно определены. А наши менеджеры прекрасно разбираются в своей области и часть связанную с проектированием API закрывают самостоятельно или при помощи разработчиков до непосредственного начала выполнения задачи, так как нам важно не быть заблокированными в процессе бэкендом.
Кажется, что разработчикам не особо надо пояснять зачем нужна загрузка данных или для чего нужен неавторизованный стейт экрана. При этом про важность информации для чего фича нужна, если это не очевидно, в тексте статьи написано. Наши разработчики любят предлагать фичи и улучшать пользовательский опыт, но это делается через обсуждения и согласования, а не отдается им на единоличное решение. И задачи из разряда “Сделай экран хорошо” без описания мы не делаем.