Решение проблем: 10 правил менеджера

Рассмотрим следующую ситуацию: вы — проджект-менеджер, и на вашем проекте возникла проблема. О том, как поэтапно добраться до источника проблемы и ликвидировать ее, я подробно расскажу в сегодняшней статье.

Решение проблем: 10 правил менеджера

У меня все работает!

Существует расхожее мнение, что проблемы решают исполнители, а управленцы только ходят и мешают. Однако что происходит, если на проекте нет менеджера? Представим ситуацию: в саппорт приходит гневное письмо: «Я нажал на кнопку, а там 500-я ошибка!». Причем письмо приходит не одно, то есть проблема массовая.
(далее…)

О методе освоенного объема в разработке ПО. Изучаем PMBOK

О методе освоенного объема в разработке ПО. Изучаем PMBOKГлавная задача менеджера удержать проект в пределах «железного» треугольника. Поэтому ему просто необходимо анализировать и прогнозировать отклонения проекта по срокам и затратам. PMBOK (A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Fifth Edition, Project Management Institute, Inc., 2013) рекомендует использовать для такого анализа метод освоенного объема (Earned Value Technique).

Бытует мнение, что этот метод не применим в управлении программными проектами. Это действительно так, если мы используем «водопадную» модель процесса разработки, в которой на верхнем уровне декомпозиции находятся производственные процессы: анализ, проектирование, кодирование, тестирование, документирование. Даже закодировав 90% требований, мы, к сожалению, ничего не можем сказать о готовности нашего продукта. Может оказаться так, что при проектировании была допущена ошибка и большую часть кода придется переписывать.

Однако, если иерархическая структура работ нашего проекта, ориентирована на итеративную и инкрементальную разработку, то на верхнем уровне декомпозиции находятся компоненты проектного продукта, а на следующем — их функционал. В ‘том случае метод освоенного объема вполне себе применим. Поскольку, если в проекте реализованы, протестированы и документированы 50 % функциональных требований (а лучше, если еще и представлены заказчику), то есть все основания полагать, что осталась приблизительно половина проектных работ.

Суть метода оценки проекта по освоенному объему заключается в следующем.
(далее…)

Принципы успешной техподдержки

Принципы успешной техподдержки

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

Немного об авторе: никакого психологического образования не получал, курсов общения с клиентами не проходил, так что все выводы основываются исключительно на личном опыте. Я начал работать в технической поддержке более 8 лет назад, в компании Acronis, тогда еще совсем небольшой, а штат техподдержки не превышал 10-15 человек. Сегодня в техподдержке участвует более 250 человек, поддерживая клиентов на девяти языках мира. Со временем я прошел все этапы — от работы в небольшом коллективе с практически нулевым уровнем личной ответственности до контроля и взаимодействия в большой инфраструктуре, включающей автоматический сбор статистики по каждому сотруднику для замеров его личного KPI (key performance indicators).

Благодаря длительному общению с пользователями (как правило, англоговорящими) сами собой выкристаллизовались манеры успешного общения — что именно нужно делать и как себя вести, чтобы клиент остался доволен. Эти правила одинаково применимы не только к технической поддержке программных продуктов, но и к общению с клиентами в любой другой отрасли, так что, надеюсь, сей опус будет полезен не только узким специалистам, но и пригодится в повседневном общении. Лично мне это сильно помогло.

(далее…)

Учет отработанных часов: за и против

Учет отработанных часов: за и против

Привет, Хабр!

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

(далее…)

Цикл зрелости технологии (Hype cycle) Gartner — при внедрении новой системы на предприятии

image
В 1995 году исследовательская компания Gartner предложила hype cycle — кривую зрелости технологии, графически представляющую стадии, через которые проходит технологическое новшество в ходе своего становления.

Данный феномен наблюдается при появлении любой новой техники, будь то появление планшетов на рынке или внедрение новой CRM системы на предприятии.

Про то как эта кривая работает в части электроники, написано много статей.

А вот как она работает в ходе внедрение новой системы в организации?
(далее…)

6 заблуждений в методологии «Бережливый стартап» («Lean Startup»)

6 заблуждений в методологии «Бережливый стартап» («Lean Startup»)
Привет, хабражители! Каждый день в мире появляется и исчезает огромное количество стартапов. В разных странах, в разных сферах. Многие предприниматели мечтают найти формулу успеха в какой-то книге по личностному росту или на конференциях и других мероприятиях. Большого внимания заслуживает книга Эрика Райса — «Lean startup», положившая начало популярному движению в стартаперской культуре. Модель «Бережливый стартап», набирающая популярность в России и СНГ, помогает строить стартапы малыми ресурсами, за счёт уменьшения циклов разработки. Все в этой модели вроде бы очень хорошо и «must read» предпринимателям, но некоторые нюансы описаны ниже и будут очень полезны для ваших будущих и текущих проектов.
(далее…)

Как я был идеальным заказчиком

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

Как я уже говорил, я много лет занимался работой с заказчиками в софтверной компании. Так вот – мне приходилось работать с разными заказчиками – с отечественными и с зарубежными, с международными корпорациями и со стартаперами-одиночками.

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

Я работал со странными людьми, которые составляли ТЗ в половину странички, с неадекватами, которые переписывали спецификацию раз в неделю, с мудаками, которые считали себя рабовладельцами. Мы делали фичи, которые не поддерживало железо, разрабатывали приложения под ось, которая еще не вышла и адаптировали под ретину дизайн, нарисованный ребенком в редакторе Paint. Я работал с психами, которые грозились миллионными штрафами за день просрочки промежуточного релиза.

Я имел дело с перекупщиками, которые понятия не имели, чего хочет конечный покупатель, я встречал неадекватов, которые понимали как надо только после того, как мы сделаем, как просят.

Я работал с заказчиками, которые «я вообще-то тоже программист» и пытались учить нас делать свою работу. Я знаю, что такое переделывать всё с нуля по три раза за проект.

Однажды у меня был заказчик, соскочивший с проекта, потому что у него сгорел офис со всем железом и данными. Однажды нам пришлось за 200 баксов делать клон, хотя нет – продвинутый клон родного яблочного приложения в то время, когда они еще не открыли сторонним разработчикам доступ ко многим своим фичам.

В общем, я работал со всеми видами невозможного и невыполнимого. Я понимаю, каково делать то, не знаю, что, так, чтобы еще вчера было готово.

Так вот — каждый раз, когда я встречал очередного «чего там работать, сделайте как в фейсбуке» клиента, я давал себе слово, даже нет – я клялся могилами предков, что вот уж я бы на его месте так себя не вел. Я бы на его месте работал так, что разработчик еще и приплачивал бы за удовольствие иметь со мной дело. Уж я бы на его месте мог бы стать просто самым лучшим заказчиком. И однажды я им стал.

(далее…)

Установка «Redmine» на «Linux Ubuntu» с прозрачной аутентификацией в домене (Apache, Passenger, RVM, MySQL)

Данным постом хотелось бы начать цикл статей о том, как мы адаптировали под свои нужды трекер задач «Redmine».

Около 2-х лет назад мне пришлось достаточно сильно изменить профиль своей деятельности, и от системного администрирования уйти в разработку на фреймворке «Ruby on Rails». Нужно было адаптировать «Redmine» под нужды достаточно большого IT-отдела, а потом и под нужды компании в целом. Тогда, я столкнулся, с относительной не простотой установки «Redmine». И комплексной статьи для новичков очень не хватало!

Есть несколько способов установки ROR-приложения, которым является «Redmine». В данной статье речь пойдет об установки на web-сервер «Apache», с использованием «Passenger» и «RVM». В качестве сервера баз данных, мы до сих пор используем «MySQL» (вернее MariaDB), хотя и подумываем о переезде на «PostgreSQL».
(далее…)

Тайные Покупатели. Нужна перестройка?

image
Нас учили, что история развивается по спирали. Сначала основным методом повышения качества обслуживания был опрос реальных покупателей. Специальные люди стояли за кассами и задавали покупателям различные вопросы. Полученная информация обрабатывалась, систематизировалась, на её основе выявлялись недостатки, вырабатывались стандарты обслуживания и т.п. Затем началась эпоха Тайных Покупателей, когда под видом обычных клиентов (покупателей) в компании приходят специально обученные люди, получающие требуемую заказчиком информацию. В этом случае потребности заказчиков можно условно разделить на три категории: конкурентная разведка; проверка соблюдения работниками принятых процедур и стандартов обслуживания; мотивация персонала. Однако последнее время маятник опять пошел в другую сторону, и всё большее распространение получают EFM-системы (Enterprise Feedback Management), предназначенные для опроса реальных покупателей (как до эпохи Тайных покупателей), но уже на принципиально другом технологическом уровне. Правда складывается впечатление, что до России это тренд пока не дошёл, поэтому «мужики-то не знают».
(далее…)

Тайм-менеджмент: простой эксперимент

Многие из нас рано или поздно задумываются о бренности всего сущего, о том, как безрезультатно проходят дни, какими богатыми и счастливыми мы должны были быть сейчас в представлении того прошлого «Я», каким мы были целых полгода-год-два и более назад… Но, вместо того, чтобы претворить свои мечты в реальность, чтобы получить новые навыки и сменить наскучившую и бесперспективную работу, чтобы продумать и закончить свой гениальный или просто хороший проект, способный принести пользу людям, да и просто заработать много или не очень денег, чтобы просто что-то наконец-таки изменить в своей жизни к лучшему, мы встаем и идем на эту работу, мы приходим домой уставшие, запускаем «World of Tanks» на компьютере или идем в бар с друзьями и говорим себе, что сегодня мы просто обязаны отдохнуть, а вот завтра обязательно начнем что-то делать.
Или послезавтра, ведь завтра еще целый день акции с утроенным опытом…

И я не исключение.

Чтобы прервать этот порочный круг, я решил, что первым делом мне нужно стать более организованным и исполнительно, начать планировать свою жизнь и делать то, что я запланировал. И, как можно было догадаться из тегов статьи, мой взор упал на тайм-менеджмент и методику GTD.
(далее…)