Стоимость разработки vs ценность

Стоимость разработки — как она коррелирует с ценностью, которую получает заказчик в итоге? Мне кажется — никак. Разработка ПО на аутсорсе — это почти всегда Water-Scrum-Fall. Мы тщательно изучаем, планируем, оцениваем, пишем планы, рисуем диаграммы проекта и собираем ресурсы — это часть Water. Дальше мы разрабатываем итерационно, делаем стендапы, ретро, демо и прочие артефакты аджайла (может у вас Scrum-ban вообще, добавьте свой список, по вкусу) — это Scrum часть проекта. Затем мы передаем это в бета тестирование, делаем стабилизацию, релиз в продакшн и проводим окончательную приемку проекта и получаем последний транш денег — это Fall часть. Все вполне логично, снижает […]

Continue Reading

Переговоры с клиентом, манипуляции и выбивание уступок

Практически все курсы для начинающих менеджеров проекта, кроме самых больших, не содержат в себе раздел по обучению навыку переговоров. Многие менеджеры вообще не представляют себе важность этого навыка в своей работе. Тем не менее, вести переговоры и о чем то договариваться приходится очень часто. Я неоднократно наблюдал как более опытные в переговорах клиенты умело продавливают менеджера на самые разнообразные уступки, такие как бесплатная работа, скидки, увеличение объема работ и тому подобные ништяки в свою пользу. Я не буду описывать все возможные книжные переговорные сценарии и приёмы — с базой можно легко ознакомиться по многочисленным бесплатным видео тренингам (чаще всего они […]

Continue Reading

Agile в зависимости от контекста

В прошлой статье мы обсудили влияние размера команды на применение “гибких” подходов в проектах. В этот раз попробуем разобраться в влиянии производственного контекста на этот выбор. Начнем с определения терминов, которые будем использовать. Контракт — понятие аутсорс разработки, которое не имеет смысла в продуктовой разработке, там есть внутренний заказчик и ваши с ним взаимоотношения строятся по совсем другим правилам. Рассмотрим 3 основные силы проекта: Заказчик— инвестор, владелец бизнеса, который заинтересован получить бизнес выгоду от проекта Команда — технические и не только специалисты, которые выполняют проект, хотят создавать крутые системы, использовать модные технологии, уникальные продукты и так далее Пользователи — люди, которые будут использовать полученный результат, в своей повседневной […]

Continue Reading

Размер команды и Agile мышление

Продолжаю размышления на тему применения agile практик в реальной жизни. Давайте обсудим зависимость от размера команды проекта.  Photo by rawpixel.com on Unsplash до 4 В этом случае абсолютно неважно какому процессу или методологии следовать, это не окажет почти никакого влияния на результат. Тут и менеджер не нужен, от слова “совсем”. Это хакатон, стартап, что угодно, но не проект. до 7 (±2) В команде проекта пара разработчиков, один тестер, а также парт-тайм аналитик и дизайнер? Допустим, что вся команда около 7 человек. Тут оказывает влияние личностные качества ПМа и его умение работать с людьми. Использование легковесных Agile практик помогает, но еще не является критичным […]

Continue Reading

Правильный старт проекта

Речь пойдет именно о первой встрече с клиентом на старте проекта, которая называется Kickoff meeting. Как же провести его правильно и с максимальной пользой? От этой встречи очень сильно зависит ход проекта, потому что именно там будут заложены многие ожидания, обязательства и представления о том, как проект будет выполнен. Еще раз дадим определение kickoff meeting — первая встреча/созвон менеджера проекта (часть команды тоже может присутствовать, но не обязательно) с клиентом после официального подписания контракта или в случае получения формального одобрения на старт от высшего менеджмента компании пока идет формальное подписание контракта. Эта встреча требует серьезной подготовки и проработки повестки, которая должна быть […]

Continue Reading

Электронные письма, которые решают задачи на вашем проекте (перевод)

How to Write Emails that Solve Problems on Your Project Оригинал: https://pmbasics101.com/emails-project-management/ Как писать электронные письма, которые решают задачи на вашем проекте Сколько электронных писем в день вы пишете? 10? 50? Всегда ли вы получаете ответ, который ожидаете? Я уверен, что нет. Некоторые письма остаются без ответа, ответ на некоторые приходит не по существу письма, некоторые письма превращаются в бесконечную переписку с большим количеством нерелевантной информации и получателей. Это нормально, многие из нас были в этой ситуации. Но хуже всего вот что: вы не видите проблему в таком положении вещей в вашей рабочей переписке Уровень эффективности вашей переписки очень низкий. […]

Continue Reading

Несколько тезисов об оценке трудоемкости

Собирал я тут информацию об оценках трудоемкости в веб разработке, описывал стандартные проблемы и ошибки. Вот часть получившегося документа, может кому-нибудь будет полезно: Обычные проблемы при выполении заданий (нетехнические), которые существенно влияют на сроки. разрастание объема работ (scope creep) оптимистичность в плане качества (заработает с первого раза и с правильным результатом) не учтено время на необходимые вспомогательные задачи (настройка окружения, базы, выкатка, проверка и так далее) неправильно понята задача, недостаточно подробное или конкретное описание запланирован неправильный объем работ (как следствие предыдущего пункта) проблемы с коммуникациями слишком оптимистичная оценка из-за страха назвать оценку, которая не понравится руководству Давайте разберем, что делать […]

Continue Reading

Постановка задач в разработке крупного новостного портала

Довелось мне выступить на конференции айтишников и журналистов вместе с моей коллегой журналисткой. Рассказывали мы про взаимодействие между отделом разработки и другими на примере взаимодействия с редакцией. Моя часть рассказа заключалась в том, что я давал советы, как правильно ставить задачи разработчикам, если вы не технарь. Ниже привожу текст выступления их моего черновика подготовки к нему (поскольку из черновика, то иногда там я перескакиваю немного): Проблемы взаимодействия технарей и гуманитариев свойственны не только IT, но и другим областям и принципы улучшения коммуникации схожи. Самым простым способом является наличие человека, который бы выполнял роль посредника между внутренними заказчиками и разработчиками, так […]

Continue Reading

Разработка vs бизнес

Начну с отвлеченного, но полезного — прекрасный сайт с набором видео с различных IT конференций и, что очень полезно для тех, кто быстро читает, транскрипцией этих самых видео, то есть больше не надо слушать унылый голос докладчика, можно просто прочитать и выделить самое важное намного быстрее http://profyclub.ru Теперь, собственно, по теме поста: я столкнулся с тем, что часто веб разработку рассматривают в отрыве от бизнеса в целом, выделяя как что-то малопонятное и загадочное. Стандартная ситуация: менеджер придумал фичу и уверен, что внедрить ее — дело пары часов, а потом недоумевает, почему это занимает неделю или он, наоборот, думает, что на это понадобится неделя, а […]

Continue Reading

Управление и развитие

Вы можете либо управлять существующим проектом/компанией/командой, либо двигать вперед. Очень малая часть вашей активности будет направлена на обе эти задачи. Вы можете устанавливать новые бизнес процессы, оптимизировать задачи, расходы, управлять временем сотрудников, а можете планировать, ставить эксперименты, выходить на новые рынки, исследовать новые ниши, рисковать, инвестировать в новый продукт, новый способ. У каждой активности свои плюсы и минусы. Хорошо, если ваша управленческая команда идеально сбалансирована и вы вместе прекрасно справляетесь с этими задачами не подавляя друг друга, без излишней критики, только с продуктивными конфликтами. Когда “администратор” вашей команды не ограничивает сверх меры “предпринимателя”. С сожалением отмечаю почти полное отсутствие новых […]

Continue Reading