Метка: заказчик
-
Допущения и ограничения
Владимир Бычко обсуждает проблему плохих постановок задач в управлении проектами. Заказчики часто предоставляют нечёткие цели, что усложняет работу. Неопытные менеджеры могут посылать заказчика, принимать размытые задачи или тянуть время. Метод допущений и ограничений помогает структурировать задачи, минимизировать риски и согласовать ожидания, превращая «галлюцинации» в подобие ТЗ.
-
Правильное завершение проекта по разработке ПО
Завершение IT-проекта требует ревизии задач, сверки с заказчиком и подписания документов. Важно проанализировать метрики (загрузка, velocity, NPS, финансы), организовать обучение клиента и поблагодарить за сотрудничество. Ретроспектива, обратная связь и архивация артефактов закрепляют уроки, улучшая будущие проекты и сохраняя доверие стейкхолдеров.
-
Зачем нужен менеджер проекта со стороны заказчика
Клиентский менеджер в заказной разработке предотвращает хаос, обеспечивая единую точку входа, приоритизацию, контроль бюджета и доступов. Без него возникают срывы сроков, размытие ответственности и конфликты. Если менеджера нет, пиэм подрядчика берёт его функции, фиксируя решения, риски и этапы. Эффективное управление ожиданиями и итерации спасают проект от провала.
-
Как отбивать наезды заказчика
Статья описывает, как менеджерам проектов в аутсорсной разработке справляться с наглостью заказчиков. Рассматриваются типичные ситуации: требования бесплатных услуг, перекладывание задач, недовольство без конкретики, уклонение от решений и манипуляции со сроками.
-
Демо продукта заказчику
Владимир Бычко рассказывает о том, как грамотно провести демо разработанной функциональности заказчику. Как подготовить тестовый контур, структурировать подачу, обработать замечания.
-
Кто такой деливери менеджер и зачем он нужен
Статья объясняет роль деливери-менеджера в IT-структуре. Эта позиция находится на стыке проектного, технического и стратегического управления. Деливери отвечает за взаимодействие с заказчиком, курирует команды и процессы, оптимизирует метрики и решает эскалации. Работа требует сильных управленческих и коммуникационных навыков, предлагая перспективы карьерного роста вплоть до CTO.
-
Шесть распространённых ошибок при работе с требованиями
Статья описывает типичные ошибки в работе с требованиями: от их избыточной детализации до отсутствия ясности. Автор подчёркивает важность документирования, чёткого согласования с заказчиком и регулярных проверок на соответствие целям проекта. Приводятся примеры, показывающие последствия таких ошибок, и даны советы, как их избежать, улучшив процесс сбора и обработки требований.
-
Контракты в Agile
Статья раскрывает особенности заключения контрактов в рамках Agile-подхода, где гибкость и адаптация являются ключевыми принципами. Обсуждаются методы минимизации рисков и повышения прозрачности, что способствует эффективному взаимодействию между заказчиком и исполнителем. Важное внимание уделено структуре договоров, направленных на достижение реальных результатов, а не просто выполнения требований.
-
Мысли из Линкадина — 20
Мысли за апрель 2024 года. О шутках в официальных доках, своевременности, красном флажке, красивых жестах, выключенном микрофоне, регрессии к среднему, обезьянничание, ночных цитатах и многом другом.
-
Что пиэму нужно знать о коммуникациях
Как выстроить коммуникации с командой, заказчиком, руководителем.
-
Выстраивание отношений с заказчиком в зависимости от его темперамента
Пост рассматривает, как выстраивать отношения с заказчиками разных типов темперамента по теории Гиппократа-Галена: холерики, сангвиники, меланхолики и флегматики. Холерики ценят краткость и решительность, сангвиники — дружелюбие и гибкость, меланхолики — эмпатию и детализацию, флегматики — точность и формальность. Для каждого типа предложены конкретные стратегии взаимодействия и отчётности.
-
Договорённости задним числом, почему это плохо
В этом посте автор делится историей о том, как он работал в аутсорсинговой компании без четкого договора и изначально оговоренного объема работ, что привело к постоянным изменениям требований от заказчика и, в конечном итоге, к его увольнению. Автор подчеркивает важность документирования обязательных требований и рекомендаций для избежания подобных ситуаций в будущем.