Тимлид и Бизнес
в продолжение про цели и задачи ...
Основная задачи коммерческой организации
Основная задача коммерческой организации - это получение прибыли. Данная задача решается тремя способами:
А дальше все возможные хотелки бизнеса - это реализации выше описанных трёх способов.
Бизнес не существует для того чтобы дать работу программисту или тимлиду. Основное в бизнесе - это встреча товара с покупателем. Организационная структура, часть процессов и IT - это всё подготовительные этапы.
Крайне часто команда и тимлид игнорируют основную задачу коммерческой организации при общении с бизнес заказчиком и разработке технического решения.
SPOR - single point of responsibility и SPOC - single point of contact
При взаимодействии бизнеса и тимлида существует два понятий:
Единая точка ответственности и единая точка контакта используются бизнесом для решения трёх основных моментов:
Бизнесу интересен положительный пользовательский и прибыли компании. Он ждёт от тимлида умения планировать эффективную работу команды и соблюдать сроки.
Как правило, бизнес заказчики не технические специалисты, поэтому они рассчитывают, что тимлид станет для них экспертом.
Тимлид предлагай решения и архитектуру. Тимлид не соглашайся со всеми предложениями и сроками, которые озвучивает его руководитель или бизнес. Эксперт по реализации - это ты !
Бизнес заказчик ожидает от тимлида приоретизации дефектов с точки зрения влияния на пользователей и на разрабатываемое решение. Это позволяет понять, какие ошибки следует исправлять немедленно, а какие можно оставить на потом.
Тимлид, не кидайся фиксить всё в подряд !
Партнёр / исполнитель
В зависимости от компании в которой вы работаете бизнес может относится к тимлиду как к партнёру и как к исполнителю.
Партнёрские отношения между бизнесом и тимлидом обычно приняты в продуктовых командах или когда IT разрабатывает внутренний продукт. В заказной разработки, например, в аутсорс компании, бизнес воспринимает тимлида, как исполнителя. Но бывает наоборот иногда бизнес подразделения относится к своим коллегам из IT как исполнителю , а заказчик решения в аутсорс компании относится к тимлиду как к партнёру.
А в чем же разница. Когда бизнес считает тимлида партнёром, то процесс создания программного продукта - это совместное творчество. Когда бизнес и тимлид партнёры, то тимлид и команда спокойно относится к неточностям в бизнес требованиях, бизнес спокойно относится к тому, что сроки могут двигаться из-за этого.
В парадигме, когда бизнес считает команду исполнителем, то процесс взаимодействия более жёсткий: бизнес менее лоялен к сдвигу сроков, на тимлида оказывается давление по ускорению разработки, дефекты в ПРОДе часто становятся предметом манипуляции.
Проблема PO - не настоящий бизнес, навязывает решение
Понятие бизнес заказчика довольно таки абстрактно. Какой-то конкретно бизнес подразделения а не один а существует даже много человек. Часто для взаимодействия какого-то бизнес подразделения выделяют ответственного сотрудника стороны бизнеса. Эту роль называют PO (product owner) - владелец продукта. По-хорошему владелец продукта это человек ответственный за предоставление адекватных и актуальных бизнес требований.
PO может принять решение относительно приоритетов по тем иным бизнес требованиям. PO закрывает за собой различные заинтересованные стороны от бизнеса и работают над тем, что бы найти сбалансированное решение. Это в идеале. Но часто бывает, что PO , просто навязывает тимлиду и команде решение.
Тимлид и PL
Последние несколько лет пойти в отрасли появилась такая роль как PL (Product Lead) - Лидер Продукта. В отсутствии PO (Владелец Продукта) PL берет на себя часть функций, чтобы синхронизировать заинтересованные стороны со стороны бизнеса и определить приоритеты по задачам для команды. Когда есть PL, то для тимлида именно он становится основным контактом по обсуждению бизнеса.
PL не является напрямую представителем бизнеса, но от тимлида ожидает тоже самое, что и бизнес :