Если вы когда-либо занимались разработкой приложений на заказ, то наверняка знакомы с довольно рутинным процессом расчета стоимости и сроков реализации проекта. И ладно бы, если расчет проекта выполнялся лишь единожды, но зачастую потенциальные заказчики не могут уложиться в бюджет, и начинают на ходу менять требования к продукту:

— Это слишком дорого, что если сделаем без функции Х?
— *делаем расчет* Столько.
— Все равно дорого, а сколько будет стоить разработка только под платформу Y?
— *делаем перерасчет* Столько.
— Ух ты, то есть, если мы откажемся от платформы Y, то сможем сделать не только Х, но и Z?
— *очередной перерасчет* Увы, нет.
— Жаль, тогда давайте сделаем без Z, во сколько нам обойдется?

Стандартные пути упрощения расчетов, такие как установка фиксированной стоимости дня работы сотрудника или компании, как правило ведут к потере точности результатов и все равно не избавляют нас от ручных вычислений.

Но, как и любой другой процесс, характеризующийся словами “рутина”, “точность” и “вычисления”, подобные расчеты скорее всего могут быть автоматизированы. Давайте проверим, действительно ли это так.

— Привет! Ну ты как, кто, где? — давно не виделись.
— Да я менеджер ИТ-проекта в большой компании.
— О, PRINCE, риски, экстремальное управление, финансы. Сложно!
— Да не. Так, ТЗ от клиента технарям и обратно таскаю за деньги. Фигня.

Вот такой вот реальный диалог. И, думается, диалог актуальный для многих компаний, особенно, если они не входят в десятку крупнейших вендоров и интеграторов, где процессы всё же отлажены и проекты выглядят именно как проекты. Понятно, почему многие компании малого и среднего бизнеса отворачиваются от самого понятия «проект» и работают как карта ляжет. В таких условиях работа прожект менеджера больше похожа на работу надсмотрщика, который приходит к программистам и просит быстрее накодить фичу, потом идёт к тестерам и призывает тестировать прямо сейчас и без критикалов, потом идёт с тимлидами разворачивать это на продакшене и с фиолетовым лицом приносит баги от клиента, причём независимо от того, минорный баг или критический, — лицо всегда одинаково фиолетовое, а речь начинается со слов: «У клиента всё упало». Правда, ситуация кажется нездоровой? Давайте о ней поговорим.


Типичный прожект менеджер, который не очень понимает, что такое управление проектами

Теоретики управления проектами говорят, что до 78% проектов не выполняются в срок, либо выходят за рамки бюджета. Любой, кто сталкивался с задержками проекта и срывом дедлайна сразу назовет вероятные причины. Это плохо сформулированные цели проекта, нереалистичные сроки, нехватка ресурсов и неэффективная коммуникация в команде.

Эта статья была написана в сотрудничестве с Беном Сейцем. Бен является экспертом в сфере корпоративных и медиа услуг с опытом работы в этой области свыше 20 лет. Сейчас он работает в Tableau Software.

Customer Success менеджеры больше не являются чем-то необычным. Все больше компаний открывают эту позицию либо в уже существующих отделах, либо формируют новую команду с нуля. Но, несмотря на популярность профессии, не каждый сможет дать четкий ответ на вопрос «Чем же все-таки Customer Success менеджер занимается?». Компании определяют данную роль по-разному. В одних случаях упор делается на коммерческую составляющую работы, в других – на глубокое понимание продукта и практики его успешного внедрения и использования.

Какие-то детали могут отличаться, но в целом большинство CSM-ов занимаются установлением долгосрочных отношений с клиентами, предотвращением оттока клиентов, донесением ценности продукта до клиента и управлением организационными изменениями в компании клиента.

Эта статья написана совместно с Питером Лайоном. Питер является вице-президентом Customer Success в компании Brightflag и сооснователем Customer Success Network

Каждый Customer Success менеджер (CSM) должен хорошо уметь выстраивать коммуникацию со своими клиентами. Это общий навык, но он потребует от вас постоянной работы над целым рядом своих поднавыков. Один из которых — способность эффективно готовить и задавать вопросы.

В данной статье мы подробно это обсудим. Разберем разницу между эффективным и неэффективными вопросами и предложим ряд приемов, которые вы сможете протестировать сразу после прочтения.

Эта статья написана вместе с Екатериной Корнеевой (Wrike, Customer Success Manager). Екатерина является профессионалом с 4-летним опытом работы в продажах и клиентском сервисе.

В сегодняшнем мире высоких технологий часто продажа продуктов строится на модели, основанной на подписке (SaaS). С одной стороны, интернет стер границы между странами и выровнял игровое поле – крохотные стартапы могут конкурировать на международных рынках с признанными корпорациями. С другой, – он породил массу головной боли для директоров и владельцев бизнеса, привыкших работать по традиционной модели. Сегодня ваша компания вынуждена конкурировать все с большим количеством участников рынка.

В традиционной модели компания получала основную часть дохода в момент продажи продукта. После продажи она могла не делать столь большой ставки на предоставление высококлассного клиентского сервиса.

Ситуация с новой моделью, основанной на подписке, совершенно иная. Сейчас компании получают относительно маленький процент дохода в момент продаж, а основным источником прибыли становится предоставление ценности клиенту на непрерывной основе. Ключевая задача – угодить клиенту так, чтобы он продолжал обновлять свою подписку. Но иногда клиент все-таки принимает решение больше не пользоваться вашим продуктом. В SaaS-бизнесе мы называем это «отписка от продукта» или “churn.” Мы сформулировали 10 общих причин отписки от продукта и предложили решения для каждой из них.

Сегодня на рынке представлен широкий ассортимент решений по управлению проектами. С их помощью компании, имеют возможность существенно повысить эффективность процессов, получить четкое понимание, кто занят какой работой, сэкономить время и избежать стресса в команде. В конце концов, это модно. Но есть немало сценариев, в которых компания, на самом деле, не готова ко внедрению решения по управлению проектами. В этой статье мы обсудим несколько примеров таких сценариев, и поговорим о том, что должно измениться в вашей компании, чтобы внедрение решения принесло ощутимые результаты

Есть две ключевые причины, по которым компании, как правило, принимают решение о внедрении сервиса по управлению проектами. Первая заключается в том, что правильно подобранный сервис может решить как ряд текущих проблем, так и будущих, связанных с ростом компании. Вторая причина — повышение эффективности бизнес — процессов в целом. Разумеется, данные причины не являются взаимоисключающими — компании нередко внедряют решение для достижения всех целей сразу.

Когда организация принимает решение о внедрении, всегда наблюдаются схожие паттерны, например, ярко выраженный энтузиазм руководства на ранних этапах. Менеджмент ожидает быстрых результатов, улучшения показателей. Разумеется, все не так просто, и из-за ряда возникающих проблем все идет не по плану. В данной статье я разберу 6 типовых проблем, из-за которых решение по управлению проектами не приносит результатов. И, разумеется, предложу варианты решения для каждой из них.

Данная статья не претендует на то, чтобы быть универсальным рецептом, мы постараемся в ней описать те проблемы, с которыми мы столкнулись, и их решения в проекте, который нам достался после 3 других команд.

Вначале коротко опишем суть проекта. Есть доктора в клиниках, которые на специальные устройства надиктовывают информацию о пациенте и его визите. Затем эта информация переводится в текстовый вид (за это отвечает специальное подразделение, сотрудники которого слушают и набирают текст), текст проверяется, происходит заполнение шаблона. Потом происходит движение по Workflow, который включает в себя разные стадии с различной бизнес-логикой, потом происходит интеграция с несколькими внешними системами. И, наконец, печатается письмо пациенту и отсылается. А работа через некоторое время архивируется (но при этом она может быть восстановлена по необходимости).

Данная статья будет полезна как аналитикам, так и менеджерам, занимающимся сбором и анализом требований. В ней описаны основные методики сбора требований, а также их плюсы и минусы. Возможно, что-то вы уже применяли на практике, а о чем-то, возможно, не знали. В общем, эта статья для всех тех, кто уже занимается бизнес — анализом или только планирует пополнить ряды аналитиков.

Каждому разработчику знакома ситуация, когда реализация новой возможности в системе занимает большое количество времени, но релиз уже близко, а тимлид или менеджер проекта пятый раз за день задают уже надоевший вопрос: “Ну когда будет готово?”. И тогда встает непростой выбор — сделать все правильно и не уложиться в сроки релиза или реализовать минимально работающий, но не идеальный с точки зрения технического решения, функционал. Очевидно, что в большинстве случаев будет выбран второй вариант, так как релиз и предоставление результата клиентам здесь и сейчас важнее чистоты кода и архитектуры системы. Но проходит несколько месяцев, и вот уже старое не идеальное техническое решение мешает реализации другого функционала. И дальше такие решения будут накапливаться в огромный ком. Разбираясь с этой проблемой, очень важно сделать правильные выводы и выбрать нужное решение. От этого решения будет зависеть дальнейшая судьба всего проекта. В данной статье мы постараемся разобраться с природой технического долга и посоветовать пути его устранения.

На практике мы часто сталкиваемся с тем, что руководитель проекта хочет ускорить процесс разработки — его не устраивает скорость поставки нового функционала. Как правило такие клиенты нуждаются в сложных продуктах вроде системы управления госпиталем, системы торговли на бирже, банковских системах, ДБО.

В таких случаях можно подключить новую команду специалистов, наладить процессы в уже существующей или объединить и то, и другое. Рассмотрим, какие плюсы и минусы есть у каждого подхода. Сразу оговоримся, что в статье рассматривается разработка крупных и сложных проектов (больше 10 000 часов).

Незнакомым с разработкой программного обеспечения может показаться странным, что у проекта есть и менеджер продукта, и менеджер проекта. Разница в том, что первый отвечает за определение продукта, а второй отвечает за состояние проекта и отчётность перед заинтересованными сторонами, если дата сдачи под угрозой.

Менеджеры проектов, как правило, стремятся обеспечить предсказуемость сроков путём стандартизации и соблюдения цикличности процессов. В этих процессах основное внимание уделяется отчётности по статусам, чтобы отслеживать прогресс. Общепринятое мнение, что чем тщательнее отслеживать процессы, тем более предсказуемым станет график проекта, и тем выше вероятность, что проект сдадут в срок.

Не так давно, я открыл для себя, систему управления проектами на базе методологии Scrum Описания Scrum'd на Хабре я не разыскал, в связи с этим, под катом мое краткое описание.

Везде ли применимо проектное планирование

Любую деятельность компании или отдельного человека можно разделить на два состояния:

1. Я делаю (сделаю) что-то сейчас;
2. Я буду это делать в будущем.

Первое состояние очень популярно в торгово-закупочной деятельности:

• купить прямо сейчас;
• заказать прямо сейчас;
• позвонить прямо сейчас.

На вас сваливается десяток задач которые надо сделать прямо сейчас. Как правило, это задачи на «на пять минут», хотя иногда подготовка к выполнению самой задачи может занять и больше пары часов. Если такое происходит, тогда весь поток задач, которые надо сделать «прямо сейчас», останавливается, пока короткая задача не будет завершена, Однако, каким-то мифическим образом все такие задачи «рассасываются» к концу недели.

Последние 10 лет для ведения проектов мы пользовались такими системами как YouTrack, Jira, Asana, Slack, SmartSheet, BaseCamp, Trello и даже белой доской, а также постоянно тестировали что-то новое. По нашему мнению, главная проблема всех систем управления в том, что люди в компании попросту забивают на её использование. А было бы здорово, если информация на все отделы распространялась из одной системы и вся команда сама активно постоянно ей пользовалась.

И настал момент, когда на выходных решили сделать свой инструмент для планирования и управления. Мы были уверены, что на эффективность команды из 30 человек действительно сильно влияет система ведения задач.

Для начала хотели реализовать 2 вещи:

• Секундомеры на каждой задаче, потому что было ощущение, что это позволит точнее понимать как расходуется время в команде;
• Универсальность. Предполагали, что отдел разработки, поддержки и все остальные отделы могут работать в одной системе.

Мы с головой ушли в это ответвление компании, разработка идёт уже 10 месяцев, а с нового года взяли ещё человека на мобильные версии. Сейчас открыто бета-тестирование, более 50 команд активно пользуется нашей системой. Под катом хотим поделиться тем, что у нас получилось и рассказать о том, какие кастомные подходы к управлению проектами оказались провальными.

Что самое важное в организации команды? Может построить планы?

Чуть больше года мы делаем свою систему управления проектами. Не так давно база активных пользователей перевалила за 1000 и появилась крутая возможность — изучать статистику того, как компании подходят к организации процессов.

Что делают успешные команды и чего не делают разваливающиеся за неделю? Что важнее — назначить на каждую задачу исполнителя или проставлять дедлайны, а может самое важное ставить приоритеты? Есть ли действие, которое значительно увеличивает срок жизни проекта?



И оказалось, что есть простой ответ. Обнаружив его, мы резко приостановили работы над функциями и всей командой сфокусировались на мобильном приложении…

За последний месяц я провел 71 обучающий скайп-звонок с самыми разными компаниями. Задачей было внедрить разрабатываемую нами систему управления проектами. Запрос у всех согласившихся на такой формат примерно один и тот же — “Как втянуть команду в систему ведения проектом и в сам проект?”. Или проще говоря: “Как сделать так, чтобы все работали?”.

Первые скайпы были длинными и не слишком результативными, но начиная с 15-го я нащупал сценарий и стал наполнять таблицу выдаваемых предложений, зависящих от компании и ситуации.



В этой статье — 10 ключевых рекомендаций по затягиванию команды в проект. Все высказанные ниже идеи подходят для работы в любой системе, но некоторые примеры приведены с интерфейсами нашего YouGile.

Важный факт — участники компаний после часового скайпа работали в нашей системе в 8.5 раз активнее в сравнении со средним пользователем. И в 2.3 раза активнее в сравнении с теми, кто согласился на скайп, но позднее отменил мероприятие.

Я хочу поделиться своим опытом использования MS Project для управления проектами по разработке программного обеспечения. Я уже лет 10 занимаюсь управлением проектами,
и в результате у меня родилась некоторая методология использования MS Project, которая позволяет получить от него немалую пользу и при этом меньше зависеть от его недостатков.

Введение

В этом топике я хочу представить вам, дорогие читатели, пересказ вебинара от человека, чьё имя не нуждается в представлении. Для того, чтобы изложить часовой вебинар в виде небольшого топика, мне пришлось значительно ужать комментарии автора, поэтому я сознательно не помечаю топик как «перевод». В этот раз Стив МакКоннелл решил поделиться с нами своим опытом в виде коротких тезисов, в которых он отражает самые страшные ошибки при оценке трудоёмкости разработки программного обеспечения. В 1998 году читатели журнала Software Development назвали Стива одним из самых влиятельных людей в индустрии разработки программного обеспечения на равне с Биллом Гейтсом и Линусом Торвальдсом. Стив — автор книги «Software Estimation. Demystifying The Black Art» — одной из самых популярных книг в области оценки трудоёмкости разработки ПО. Надо признаться, что вебинар был проведён относительно давно (июнь 2009 года), но информация, представленная там, совсем не устарела. Сам топик будет построен следующим образом. Заголовки будут достаточно точно переведены из презентации, которую показывал Стив, а в остальном я постараюсь отразить только основные мысли, чтобы не перегружать топик. Если кто-то посчитает, что ту или иную мысль я излагаю неправильно — милости прошу в комментарии, можно будет меня поправить.