Страницы с тегами : управление проектами
3 причины не верить почасовой ставке
За неделю ко мне обратились две компании, предлагали проект на SharePoint и спрашивали какая у нас (vnextsoft) почасовая ставка. Они не говорили какую конкретно задачу надо решать или какой портал сделать, их просто интересовала ставка.
Алиса в стране ИТ-проектов
Про заказчиков
Шляпных дел мастеров я уже видела. Мартовский Заяц, по-моему, куда интереснее. К тому же сейчас май — возможно, он уже немножко пришёл в себя.
— Ничего не поделаешь, — возразил Кот. — Все мы здесь не в своем уме — и ты, и я!
— Откуда вы знаете, что я не в своем уме? — спросила Алиса.
— Конечно, не в своем, — ответил Кот. — Иначе как бы ты здесь оказалась?
Про анализ требований
Не грусти. Рано или поздно все станет понятно, все станет на свои места и выстроится в единую красивую схему, как кружева. Станет понятно, зачем все было нужно, потому что все будет правильно.
Не все ли равно, о чем спрашивать, если ответа все равно не получишь, правда?
— Как мне попасть в дом? – повторила Алиса громче.
— А стоит ли туда попадать? – сказал Лягушонок. – Вот в чем вопрос.
– Ты что, не знаешь, что такое «это»?
– Я прекрасно знаю, что такое «это», когда я его нахожу.
Всё страньше и страньше! Всё чудесатее и чудесатее! Всё любопытственнее и любопытственнее! Всё страннее и страннее! Всё чудесится и чудесится!
Про написание Технического Задания
Я видала такую чепуху, по сравнению с которой эта чепуха — толковый словарь.
Как она ни пыталась, она не могла найти тут ни тени смысла, хотя все слова были ей совершенно понятны.
Если в мире все бессмысленно, — сказала Алиса, — что мешает выдумать какой-нибудь смысл?
Думай о смысле, а слова придут сами.
— Этой ужасной минуты я не забуду никогда в жизни.
— Забудешь, если не запишешь.
Правильность формы несущественна!
Про управление проектом
План, что и говорить, был превосходный: простой и ясный, лучше не придумать. Недостаток у него был только один: было совершенно неизвестно, как привести его в исполнение.
Любое приключение должно с чего-либо начаться... банально, но даже здесь это правда...
— Скажите, пожалуйста, куда мне отсюда идти?
— А куда ты хочешь попасть? — ответил Кот.
— Мне все равно… — сказала Алиса.
— Тогда все равно, куда и идти, — заметил Кот.
— … только бы попасть куда-нибудь, — пояснила Алиса.
— Куда-нибудь ты обязательно попадешь, — сказал Кот. — Нужно только достаточно долго идти.
Она всегда давала себе хорошие советы, хоть следовала им нечасто.
Не понимаю, как он может когда-нибудь окончить, раз он и не собирается начинать.
Делать ей было совершенно нечего, а сидеть без дела, сами знаете, дело нелегкое.
— С чего начинать, Ваше Величество? — спросил он.
— Начни с начала, — важно ответил Король, — продолжай, пока не дойдешь до конца. Как дойдешь — кончай!
То ли колодец был действительно уж очень глубоким, то ли летела Алиса уж очень не спеша.
Нельзя делать то, что нельзя.
Не понимаю, как он может когда-нибудь окончить, раз он и не собирается начинать.
Про оценку проекта
Алиса засмеялась. «Нет смысла и пытаться, — сказала она, — нельзя верить в небылицы». «Я полагаю, у тебя не слишком много опыта, — сказала Королева. — Когда я была моложе, я имела обыкновение делать это по полчаса в день. Да что там говорить, иногда я успевала поверить не менее чем в шесть небылиц ещё до завтрака».
Пока думаешь, что сказать, — делай реверанс! Это экономит время.
А у нас больше одной пятницы разом не бывает.
Знаешь, сколько стоит его время? Тысяча фунтов одна минута!
Про команду
Чем ниже голова, тем глубже мои мысли.
Лучший способ объяснить – это самому сделать!
Лестные слова часто вынуждают людей действовать.
Про ИТ-индустрию в целом
Ну а здесь, знаешь ли, приходится бежать со всех ног, чтобы только остаться на том же месте, а чтобы попасть в другое место нужно бежать вдвое быстрее.
Как проектному менеджеру провалить продажу проекта
В статье речь пойдет о типовых ИТшных проектах, которые продают большинство компаний-интераторов\аутсорсеров\разработчиков.
Продажи проектов отличаются от продаж товаров и большинства услуг одним важным свойством – проект нельзя “пощупать” до того, как он реализован в какой-либо мере в силу достаточно большой уникальности. Поэтому большинство тактик, направленных на то, чтобы подсадить покупателя на товар\услугу, а уж потом брать с него деньги, в случае продаж проектов не работают.
Я уже довольно долго занимаюсь продажами ИТ-проектов и часто видел как прекрасно построенные, с точки зрения стратегии, продажи с треском проваливались на пресейле.
Способ №1
Банально затянуть с предоставлением предложения. Казалось бы процесс закупки, особенно в крупных компаниях, может занимать месяцы. Тем не менее люди не любят ждать. Если через неделю после встречи с заказчиком вы не можете предоставить предложение, то вероятность успешного закрытия сделки падает. А если вы тянете месяц, то вероятность становится близкой к нулю.
Происходит такая ситуация очень часто. В некоторых компаниях каждый пресейл это сам по себе проект, который требует много разных специалистов и десятки часов работы каждого. С учетом загрузки людей, перекладывания ответственности друг на друга, процессных барьеров (например кучи согласований) сделать предложение в разумные сроки практически невозможно.
И это при том, что скорость в современном мире – один из важных факторов дифференциации от конкурентов.
Способ №2
Следующий по популярности способ – поздно показывать результат. Типичный план проекта, составляемый ПМами выглядит так:
- Обследование
- Написание ТЗ\Рисование архитектуры\Другие бумажные работы
- Разработка
- Тестирование
- Внедрение и настройка
- Сдача проекта
Получается что заказчик увидит результат только на пятом пункте, при этом пункты 1-4 в совокупности занимают 80% и более затрат. Для оценки проекта такой план может быть и хорош, но для заказчика он явно говорит о том, что заказчик рискует 80% бюджета фактически без возможности что-либо поправить.
При этом большинство ПМов понимают проблему, но даже не пытаются её решать, так как построение плана с итерациями, частичными поставками и ранним внедрением может привести к раздуванию плана.
В одной компании на пресейлах даже прототипы не делают, мотивируя тем, что любое прототипирование - это фиксация некоторых архитектурных решений, которые потом дорого будет исправлять (как архитектору мне такое кажется странным).
Способ №3
Отличный способ провалить продажу проекта – это вываливать на клиента свои проблемы. Чаще всего это проявляется в двух подходах:
- Составляется список ограничений, в которых готов работать исполнитель, которые крайне неудобны заказчику. Например в проектах перехода на новую версию какой-либо системы требуют полную документацию по всем настройкам и кастомизациям, которая отсутствует чуть реже, чем всегда.
- В плане проекта появляются “работы”, которые не имеют фактического результата и служат фактически риск-буферами. Объем этих буферов составляет значительную часть объема проекта.
Все прекрасно понимают, что в проектах есть риски. Если бы рисков не было, то заказчик вполне мог бы и своими силами обойтись. Но любой заказчик прекрасно понимает, что при таких подходах риски пытаются полностью переложить на него, даже если это внутренние проблемы исполнителя.
Первопричина всех проблем
Менеджеров проектов учат, что успех – это попадание в “треугольник” объем-сроки-бюджет. Многие процессы управления проектами рассчитаны на то, чтобы этот треугольник не менял размеры.
На самом деле успех проектов заключается в ценности, которую вы принесли для заказчика и во взаимоотношениях, которые вам удастся построить.
Так как менеджер проектов участвует в процессе продажи практически с самого начала (а иногда и сам выступает в роли продавца), то ему просто необходимо с самого начала настроиться на повышение ценности для заказчика и на выстраивание долгосрочных партнерских отношений.
Постоянно добавляя ценность вы можете маневрировать объемами и сроками проекта, а при хороших взаимоотношениях сможете снять свои риски и получить больше денег. Но для этого надо как минимум в самом начале управлять рисками заказчика в первую очередь, а не применять способы, описанные в этой статье.
Как поставщики решений SharePoint обманывают заказчиков
На днях получит вот такой коммент в обсуждении на Хабрахабре:
Государственный университет в регионе N хочет себе СЭД, пользователей на 100. Кроме СЭД хочет простенький портал, телефонную книгу, новости, календарики.
На Sharepoint Server денег тратить не хочется, да и нет необходимости — рейтинги, социальные сети, политики хранения контента не в почете у сотрудников.
Поэтому решили купить СЭД на Foundation, заплатив только за СЭД-надстройку (будем считать что лицензионные права на Foundation у них уже есть).
За 2-3 года документов скопилось около 60-80 тыс. (по всем группам). По ним нужно, в самом простейшем случае:
а) осуществлять быстрый и легко настраиваемый поиск (по конкретным атрибутам и без управляемых метаданных) по любым элементам и с учетом прав
б) быстро искать и исполнять задачи. задач при этом становится = (кол-во документов * 5)Если знаете способ реализовать это на Foundation «изкаропки», пожалуйста, расскажите, очень интересно.
Исходный пост и обсуждение можете почитать по ссылке: http://habrahabr.ru/post/210844/#comment_7260770
Используя SharePoint Server, даже версии Standard, можно настроить быстрый и удобный поиск по документам и задачам. Это даже не потребует программирования, достаточно будет за день-два выполнить настройку поисковых представлений.
Решение, предлагаемое автором коммента, требует создания баз данных, custom service applications, собственного интерфейса пользователя и кода для привязки к стандартному функционалу. При очень хорошем раскладе такая разработка займет около двух недель.
Кажется, что решение на Foundation действительно выгоднее. Но на самом деле это обман.
Считаем стоимость
Так как решение делается для Государственного Университета, то стоимость лицензий на продукты Microsoft будет примерно в 10 раз ниже среднерыночной.
Я зашел на сайт http://www.msbuy.ru/ (не реклама, просто первый удобный калькулятор из выдачи гугла) и посчитал полный объем лицензий:
- SharePoint Server – 1 шт
- SharePoint Server Standard CAL – 100 шт (на пользователя)
- SQL Server Standard Core – 2 шт (4 ядра)
У меня получилось 797 182.84 рублей. Лицензии на Windows Server не считал, так как они также нужны для Foundation. Для госуниверситета цена выйдет около 80 000 рублей. SharePoint Foundation, работающий на SQL Express, обойдется фактически бесплатно.
Даже если взять самых дешевых специалистов SharePoint, то их стоимость для заказчика составит не менее $60\час. Для SharePoint Server понадобится 16 часов работ по настройке представлений, для Foundation объем работ вырастет до 80 часов.
В деньгах:
- Server – 16 часов = $960 = 33 600 рублей.
- Foundation – 80 часов = $4 800 = 168 000 рублей.
Внезапно решение на Foundation оказалось дороже, чем на Server, даже с учетом цены лицензий последнего.
Но и это еще не все.
Совокупная стоимость владения
Нужно понимать, что расчет выше касается одного аспекта функционала. Зачастую в решениях на Foundation создается много кода, имитирующего стандартный функционал платной версии SharePoint - поиск, профили пользователей (для хранения данных о пользователе), управляемые метаданные (структурированные справочники) и жизненный цикл документов. Например в SharePoint Standard справочник сотрудников (aka телефонная книга) и новости на портале можно сделать за два часа прямо в браузере. Подобное решение на Foundationобойдется в пару тысяч долларов минимум. В совокупности решение на Foundation, начинает стоить на порядок больше, чем решение на платной версии.
Вполне возможно, что поставщик решений в таком случае будет пытаться продать “продукт”, с уменьшенной начальной ценой, но с сервисным контрактом, по которому за три года объем выплат превысит стоимость разработки. Неопытным покупателям кажется что сервисный контракт является необязательным, но без него решение свалится и никто не сможет его поднять, а поменять какую-нибудь мелочь смогут только разработчики. Поэтому сервисные контракты не покупают только те, кто фактически не пользуются решением.
Обязательно стоит учитывать скрытую стоимость решений. Подробнее тут - http://gandjustas.blogspot.ru/2013/07/sharepoint.html.
С другой стороны платная версия SharePoint содержит много функционала, который можно использовать без кастомизации: поиск по внешним системам, мощные рабочие процессы согласования, совместное редактирование документов, личные узлы и удобный шаринг. Даже если не рассматривать скидку на лицензии в 90%, как для Государственных Учебных заведений, то амортизированная стоимость лицензий на одно решение оказывается гораздо ниже. Кроме того, есть программы лицензирования, по которым цена лицензий оказывается значительно ниже.
Как продают впаривают
Тоже процитирую комментарий из обсуждения:
СЭД — это не портал. Принципы разграничения прав не по элементам, а по карточкам документов, например. То же самое и при отображении. Документ в СЭД — это же не просто элемент в списке или библиотеке, это элемент, связанный с кучей всего, вроде связанных файлов, других документов, журналов, поручений (которые еще связаны с задачами). Принципы работы довольно сильно отличаются. XXX for Sharepoint нужны как раз для адаптации Sharepoint к российскому документообороту, чего из коробки никак не сделать.
Мне, как техническому специалисту, это кажется смешным. В SharePoint Standard есть наборы документов, которые позволяют связывать несколько документов в одно целое, для связанных журналов и поручений нужно делать отдельные папки в списках, чтобы можно было давать доступ сразу на группу элементов. Всю автоматизацию моно сделать в workflow или с помощью небольших кусков кода. Это абсолютно не требует баз данных, custom service application и подобных “тяжелых” кастомизаций.
Но обычный заказчик об этом не знает. Ему откровенно врут, что никак нельзя сделать стандартными средствами и обязательно нужно купить дорогую кастомизацию, чтобы все было как он захочет. При этом, конечно же, не случается так, как хочет заказчик. Но выхода у него нет, ему помогли “сэкономить”, поставив Foundaton, и теперь заказчик вынужден доплачивать вендору, чтобы действительно стало как он хочет.
Заключение
Если вам предлагают решение, которое работает на Foundaion, то вас скорее всего разводят. Оно окажется не только более дорогим по совокупной стоимости владения, но и вы попадете в сильную зависимость от вендора решения и будет сложно переключиться.
Я понимаю, что есть и хорошие решения на Foundation, которые действительно делают что-то, что не умеет SharePoint Standard или Enterprise. Но таких решений очень мало, особенно на Российском рынке. А также вам надо удостовериться, что они идеально вам подходят, ибо доработка будет дорогая.
Успех проекта SharePoint, где он?
Есть статистика, которая говорит, что более половины SharePoint проектов неуспешны (смотреть тут). С точки зрения бизнеса успешных проектов еще меньше, так как затраты оказываются выше, чем экономический эффект.
Проблема
Многие проекты SharePoint фактически ведутся по процессам разработки программного обеспечения. Все процессы разработки ставят целью разработку нового или доработку существующего ПО. Основные KPI для такого проекта – сроки, функциональный объем и бюджет. Еще говорят о качестве, но качество померить сложно и оно как-то выпадает из основных характеристик.
Негативным эффектом такого способа ведения проектов становится то, что создается много кастомного кода. Ведь нельзя делать разработку, когда нечего положить в систему контроля версий. Обучая разработчиков out-of-the-box функционал, я много раз слышал вопрос о том, что же будет в итоге лежать TFS.
Кастомный код при этом является огромной проблемой, он усложняет поддержку портала, появляются проблемы при апгрейде и попытках развития решений. Зачастую именно кастом код является причиной падений SharePoint и низкой производительности.
Казалось бы, почему просто не использовать правильную методологию? Оказывается такой методологии нет. Все что можно найти на просторах интернета – адаптация процессов разработки для SharePoint.
Как добиться успеха
В первую очередь надо фокусироваться не на поставке функционала, а на увеличении value от внедрения. Причем этот самый value надо не просто определить, а измерять. Проект считается законченным, когда достигнуты целевые показатели (KPI, связанные с value), это может случиться сразу после поставки функционала (маловероятно), а может и через год (более вероятно). План проекта должен отражать действия для достижения KPI, а не работы по созданию ПО.
Возможен и негативный вариант, когда затраты на проект растут быстрее, чем value, измеряемый в деньгах. В этом случае надо “фиксировать убытки” и закрывать проект.
Из этого следует второй принцип – делайте проекты маленькими. Чем меньше проект, тем быстрее можно достичь целевых KPI и тем меньше возможный убыток. Маленькие проекты проще запускать и проще убивать. Чем меньше проект, тем проще он поддается изменениям. Маленький проект гораздо проще аутсорсить, если своих ресурсов недостаточно. При этом можно увеличивать число проектов, запуская многие из них параллельно.
Например, вместо огромного проекта “создания корпоративного портала” на полтора года и тысячи человеко-часов, можно запустить с десяток мелких проектов, каждый со своими KPI. Буквально через месяц по каждому проекту станет ясно имеет ли смысл его продолжать.
Может казаться, что это очень сильно увеличит нагрузка на менеджера. Если вам приходилось управлять двумя-тремя проектами сразу, то десять проектов может показаться адом. Но оказывается есть зубры, которые могут управлять и 50 проектами - http://www.linkedin.com/groups/How-many-projects-can-project-37888.S.210671311. Сказывается эффект масштаба – чем больше проектов, тем проще управлять каждым в отдельности.
Последнее, но самое важное тем не менее - минимизируйте объем кастом кода, особенно при работе с server-side object model. Чем больше кода, тем дороже поддержка, тем меньше шанс на успех.
Заключение
Я понимаю, что для многих очень сложно перестроить мышление с одного большого проекта на кучу мелких, но это просто необходимо сделать. Если сложно сделать сразу, то отрезайте от большого проекта маленькие независимые кусочки и запускайте их по отдельности.
Восприятие SharePoint
Пост-перевод http://veroniquepalmer.com/2014/01/16/your-sharepoint-perception/
Не правда ли, что мы склонны видеть мир через через призму нашего опыта, но не так, как на самом деле. Возьмите SharePoint например ...
- Если вы пришли из области автоматизации работы, то SharePoint всего лишь движок workflow.
- Если вы пришли из области работы с документами, то SharePoint всего лишь хранилище документов с метаданными.
- Если вы пришли из области веб-дизайна, то SharePoint обязательно надо брендить.
- Если вы пришли из области разработки, то SharePoint обязательно требует кастомизации.
- Если вы пришли из области обработки данных, то SharePoint всего лишь панели монтиторинга.
- Если вы пришли из области обучения, то SharePoint можно использовать только после обучения.
- Если вы пришли из области управления, то SharePoint работает только если есть регламенты.
- Если вы пришли из области бизнес-анализа, то SharePoint требует годы планирования.
- Если вы пришли из области социальных медиа, то SharePoint можно использовать только с версии 2013.
- Если вы пришли из области разработки расширений, то SharePoint может работать только вашим самым продаваемым продуктом.
И так можно продолжать очень долго.
Это человеческая природа, думать, что наш путь является единственным Но это не так, это лишь один из способов. Нельзя фокусироваться на одной вещи, так как SharePoint это очень большая платформа и умеет много чего еще.
Давайте посмотрим на это другим взглядом. В первую очередь взглядом потребителя. Например, если вы не используете личные узлы, это не значит что в них нет ценности для других. Расширяйте свое видение платформы и станете более более ценным специалистом.
Наша работа требует беспристрастной оценки всех возможностей, понимания всех плюсов и минусов, чтобы создавать более качественные решения для ваших клиентов.
Нелегкая судьба Best Practices
(картинка отсюда)
Именно такое отношение к лучшим практикам встречается чуть менее, чем всегда. Можно подумать что не все знают про эти best practices. Но как только человек делает что-то не так, ему сразу же указывают как делать правильно. И что после этого происходит? НИЧЕГО. Только единицы начинают делать правильно после того как узнают про best practices, остальные продолжают жрать кактус и плакать о плохих менеджерах\вендорах\подрядчиках\клиентах\государстве.
Почему так происходит?
- Люди последовательны. Если человек уже что-то делает одним образом, то существует психологический барьер делать по-другому.
- Люди избегают потерь. Потому что в "другой путь" уже вложено много сил, и есть психологический барьер отказаться от этих "результатов" и пойти правильным путем.
- Люди не хотят быть неправыми. Есть у людей такой психологический механизм, который рационализирует любое нерациональное поведение. Даже если первоначальные действия были просто ошибкой, то человек придумает 100500 причин почему этот путь был самым правильным.
Вывод
Если кто-либо (в том числе Вы) не следуете best practices, то для этого почти никогда нет никаких рациональных причин. Когда следующий раз вы узнаете про лучшие практики в вашей области и подумаете "это мне не подойдет потому что...", остановитесь, и еще раз взгляните на картинку в начале поста.
Запись с доклада на SPC UA 2012
Прошел почти год с того момента, как я выступал на конференции в Киеве. Наконец-то организаторы выложили запись выступления.
