После написания заметки про фэйл с Кинопоиском еще лучше стало понятно одно из принципиальных различий разработки программного продукта силами своей команды и с привлечением аутсорсинга.
Если разработка отдана на аутсорсинг, то проектная команда перестает быть единым целым и состоит, как минимум, из двух частей: собственно продуктовая команда на стороне заказчика и команда разработки на стороне исполнителя.
Ключевой момент в том, что стимул к разработке успешного продукта, по большому счету, есть только у продуктовой команды на стороне заказчика. Исполнителям итоговый результат не так важен. Им же платят не за результирующий успех продукта, а за точное и в срок выполнение пожеланий заказчика. Захотел заказчик красные кнопки на синем фоне, значит будут именно такие. Захотел переделать на зеленые на желтом фоне -- пожалуйста, любой каприз за ваши деньги. Нужна ли продукту вообще форма с кнопками исполнителя, в принципе, не интересует. Этот вопрос находится в зоне ответственности продуктовой команды.
Важным следствием из этого является то, что передача информации от исполнителей к заказчикам идет по довольно узким каналам. Грубо говоря, если кто-то из тестировщиков на стороне исполнителя понимает, что в итоге получается неудобный для пользователя продукт, то у тестировщика может вообще не быть возможности передать это свое подозрение продуктовой команде.
Отсюда следует и стиль взаимодействия между продуктовой командой и командой разработки: продуктовая команда придумывает, команда разработки воплощает задуманное, ответственность за конечный результат лежит только на продуктовой команде. Отсюда и довольно жесткий стиль общения "мы придумываем -- вы делаете".
Когда продукт разрабатывается своими собственными силами, продуктовая команда одна. И все ее участники, образно говоря, сидят в одной лодке. Конечный успех разрабатываемого продукта важен для всех, поэтому стимул вкладываться в разработку должен быть у всех.
Задачами менеджмента в этом случае являются: во-первых, донесение этой простой мысли до всех участников разработки (все работают над одним продуктом, будущее для всех зависит от успеха продукта) и, во-вторых, для обеспечения условий, при которых мнение любого члена команды будет услышано.
Понятное дело, что чем больше организация и чем больше размер проектной команды, тем сложнее этого достичь. Однако, даже если на проекте работает 150+ человек, поведение в стиле "мы придумали -- вы сделали" не есть хорошо. По той простой причине, что даже рядовой тестировщик прекрасно понимает, что его рабочее место и его будущее на этом месте зависит от успеха разработки. Поэтому, если тестировщик видит, что ни красные кнопки на синем фоне, ни зеленые на желтом не превращают говно в конфетку, а на него мнение никто не обращает внимания, то он естественно начнет задумываться, а какой смысл продолжать вкалывать здесь? И чем больше будет таких настроений, тем хуже будет идти разработка, тем сложнее будет достичь успеха.
Поэтому обеспечение нормальной обратной связи между всеми уровнями иерархии в проектной команде в продуктовых компаниях -- это ключевой момент. Гораздо более важный, чем в аутсорсинговых.
PS. Нужно пояснить, почему в качестве примера я упоминал "рядового тестировщика". Имхо, тестировщики по роду своей деятельности зачастую очень хорошо понимают принцип работы программного комплекса в целом (гораздо лучше, чем программисты, которые не видят дальше отдельной фичи). Плюс к тому, тестировщики оказываются самыми первыми пользователями нового продукта. Это своего рода фокус-группа, игнорирование мнения которой, на мой взгляд, чревато.
Комментариев нет:
Отправить комментарий