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

О гибких (agile) методологиях по разработке программных продуктов информации довольно много. Но, мне пока нигде не попадалась информация (на русском) о применении agile для разработки сайтов. Я имею ввиду достаточно крупные проекты, например социальные сервисы, где подразумевается постоянное совершенствование продукта и где важен ранний запуск бета-версии. В частности, меня интересует вопрос планирования параллельной разработки дизайна и программной части проекта.

Рассмотрим типичную ситуацию.

Каждый четвёртый веб-проект не вписывается в отведённый ему бюджет, а почти в каждом третьем случае разработчики не могут закончить работу к дедлайну. Такую мрачную статистику выявило новое исследование, проведённое компанией New Bamboo, которая занимается разработкой ПО на Ruby on Rails. В опросе участвовали около ста IT-менеджеров и директоров компаний.

Главной причиной подобной безалаберности называют слишком большое количество сторон, участвующих в проекте и желающих повлиять на него. И это при том, что около половины веб-проектов создаётся силами собственного IT-подразделения компании и только 28% отдаётся на аутсорсинг.

Неприглядная картина веб-разработки дополняется и другими цифрами. Оказывается, даже после всех согласований, возможного дополнительного финансирования и продления сроков 21% проект всё равно не соответствует требованиям заказчика. Печальные цифры сохраняются не только для крупных, но и для совсем мелких проектов. Ситуация усугубляется, если заказчик требует усложнить преокт и добавить в него модные современные технологии: социальные сети, приложения электронной коммерции, фичи Веб 2.0.

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

 

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

«Дизайн сайта разрабатывался и согласовывался в течение года (в частности, оказались отвергнуты 28 начальных вариантов стилевых макетов).» Источник.

Является ли этот факт поводом для гордости, вопрос спорный. Скорее, это говорит об ошибках в управлении требованиями.

Профессор Эрик Шпикерманн (Erik Spiekermann) из Германии, основатель Metadesign, в интервью опубликованном в журнале «Мир Дизайна», говорил, что в дизайне у задачи может быть не больше двух решений.

Речь идет о практике, разумеется. И главное на практике — четкость поставленной задачи, основанная на общем видении заказчика и исполнителя.

Хотел бы рассказать о некоторых эпизодах проектного менеджмента, особенно подходов к управлению отношений с клиентом на примере веб-конторы. По словам Terentii, моего ex-коллеги, клиенты «вели с конторой, мягко говоря, по-хамски — достойные наследники традиций Солтычихи». Дело в том, что… клиент всегда прав. Итак…

Когда проект сайта Х-Банка был готов и нужно было погашать договор, менеджер проекта не смог получить платеж «с наскоку» и стал вести подобные записи:
— 20 января 11:02. звонил в банк. отв.менеджер не подошел. обещал перезвонить через час.
— 20 января 15:02. перезвонил. его не было. позвонил его руководителю. секретарь не соединила.
— 25 января 11:02. звонил в банк. отв.менеджер подошел к телефону. наорал, почему я не позвонил раньше. назначили встречу.
— 27 января 15:00. на встрече вынесли мозг, сказали все переделывать. на ТЗ в договоре не смотрели. написал им изменения, какие мы можем сделать с сохранением стоимости.
— 28 января 11:00. позвонил чтобы узнать что с е-мейл. не соединили…
И так далее.

Метод критической цепи: эффективное управление проектами с использованием буферов времени и ресурсов

Работа стремится занять все время, отпущенное на нее.
Закон Паркинсона.
Если какая-нибудь неприятность может произойти, — она случается.
Закон Мерфи.

Немного статистики

Одной из причин выделения управления проектами в отдельную область знаний является неопределенность. То, как мы управляем неопределенностью в проекте (в том числе и рисками), напрямую влияет на длительность проекта, на его успех.
По данным многочисленных исследований Standish Group¹ для традиционных методов управления проектами, только 44% проектов обычно завершаются вовремя. В среднем проекты занимают 222% процента от изначально запланированной длительности, 189% от начального бюджета. 70% проектов сокращают исходный объем работ проекта, 30% проектов закрываются досрочно.
И хотя в последнее время, с развитием инструментов и техник управления проектами, эти цифры стали уменьшаться, общая картина говорит о том, что мы как менеджеры проектов плохо делаем свою работу.
Данная статья рассматриваем использование относительно новый метод управления проектами, метод критических цепей (МКЦ), сравнивая его с традиционным подходом к управлению проектами.

Для того, чтобы познакомиться с общей идеей CCPM (Critical Chain Project Management), нужно обязательно прочесть книгу автора — Элияху Голдрата.
Она написана как художественное произведение, а не как учебник, и по-настоящему заставляет проникнуться идеей. Я попробовал сделать конспект книги в виде mindmap (щелкните на рисунок, чтобы увидеть полноразмерную карту).

Также вы можете ознакомиться с конспектом в формате mmap
Попробуйте его рассмотреть — поможет ли он вам понять основные мысли книги?

Оригинал данной записи опубликован в блоге «Управление проектами в картинках»

23 апреля в Инфоцентре прошёл семинар, автор и ведущий которого — человек-легенда Эдвард Йордон.

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

В этом топике был сделан вывод «Подменяя цели средствами, успеха не добиться!»

Хорошо, с целями заказчика определились:

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

Теперь представим ситуацию, у заказчика есть два варианта добиться конкретных целей:

1. Воспользоваться современными средствами веба, что обойдется заказчику в 40$ и пару часов на регистрацию в сервисах;
2. «Стандартный» подход, что обойдется заказчику в 4000$/год на оплату услуг вашей студии, «раскрутку» и т.д;

Вы о всех современных средствах знаете и применяете на собственных проектах, а заказчик не подозревает об их существовании.

Ваши действия?

Не кажется ли вам, что рынок заказных сайтов в значительной степени основан на том, что разработчики держат заказчиков в «счастливом неведении» об эффективных средствах достижения их (заказчиков) целей?

Уважаемый пользователь aosodoev посетовал, что «продвинутые веб-разработчики и юзеры в личных проектах применяют «модные» фишки вроде тегов, микроформатов, AJAX, интеграцию с социальными сетями», а сайты, которые делают эти разработчики для клиентов, ничем таким похвастаться не могут.Давайте посмотрим, что именно нужно заказчику. Сами по себе «модные фишки», «вебдванольности», «аяксы-фигаксы» ему не нужны. Вы удивитесь, но заказчикам не нужны и XHTML, CSS, PHP, MySQL. Даже CMS сами по себе заказчикам нафиг не нужны.

А что им нужно?

У нас в регионе современный веб и заказные сайты — это совершенно разные, практически не пересекающиеся вселенные.

Продвинутые веб-разработчики и юзеры имеют блоги, пользуются сервисами вроде Twitter, YouTube, Flickr и т.д. В личных проектах применяют «модные» фишки вроде тегов, микроформатов, AJAX, интеграцию с социальными сетями и т.д.

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

У меня этот «водораздел» въелся уже на уровне подкорки. Правильно ли это?

Предлагаете ли вы клиентам применять современные технологии и сервисы?

Если да, то какие и для чего, как преподносите? Есть ли успехи? Грабли?

* ненавижу сочетание «Сайт-визитка» :)

 

Делая что-либо, нужно сначала решить важный вопрос: на каком уровне будет все делаться.

Есть несколько моделей:
1. Подготовленный захват территории. Когда есть инвестиции (или клиент готов платить), все сначала проектируется «сверху» до последнего болтика, делается так как нужно, потом запускается.

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

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

В каждом случае свои плюсы и минусы.

Иногда попадаются такие менеджеры или бухгалтеры на стороне заказчиков, которые говорят: «Ааааа, у вас упрощенка». И делают кислое лицо. Дескать, из-за вашей упрощенки они не получат возврат НДС, 18% от стоимости.

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

Вы говорите: «Если бы мы работали не по упрощенке, то к нашей цене в 1000000 рублей добавился бы еще 18% НДС, и вы платили бы 1180000 рублей, а потом ждали бы, когда государство вернет вам 180000 рублей НДС. Работая с нами, вы не платите лишних 18% и не ждете потом их возврата, эти деньги работают на вас, а не болтаются у государства в кармане».

И тогда происходит чудесное преображение, и адекват нисходит на головы бухгалтеров, финансовых директоров и менеджеров.

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

1. Налоги
Существует основной режим налогообложения (ОСНО) и несколько спецрежимов. Один из спецрежимов — упрощенная система налогообложения (УСН, УСНО или упрощенка). Право на упрощенку имеют малые предприятия с годовым оборотом, не превышающим примерно 20 млн рублей (точную сумму можно получить, применив к сумме, указанной в главе 26.2 налогового кодекса РФ инфляционные коэффициенты). Кроме того, есть ограничение по численности штатных сотрудников (не более 100 человек) и некоторые ограничения по видам деятельности. Далее мы будем говорить только об УСНО, так как ведением учета по ОСНО не владею.

 

 

В продолжение темы о договорах хочу представить вам договор на SEO, который мы используем в нашем Интернет-агентстве.

Одна из ключевых проблем договора на SEO — за что же собственно берем деньги? Существуют три основные точки зрения. 1. за позиции в топе 2. за трафик с поисковиков 3. за работу в целом.
Брать деньги с клиентов за позиции – неверная позиция для оптимизатора. Глюки поисковика, смена алгоритма, результат работы лишь через 2-3 месяца. Все это не то, что способствует прибыли организации. К тому же такой вариант исключает предоплату. Выводить в топ по конкурентным тематикам, вкладывая деньги компании нет никакого желания.
Вариант с оплатой за посетителей более приемлемый. Но опять же как быть с предоплатой? Первые два месяца работать за счет собственного бюджета, пока посетителей мало или нет вообще?
Третий вариант – оплата за проведенный комплекс работ, наиболее интересен для seo-компании. Мы делаем – это, это и это. За эффект отвечаем своим опытом, репутацией, но никак не юридически.
Для тех, кто спросит: «а как же гарантии?» Я отвечу: а никаких 100% гарантий нет и быть не может. Оптимизатор как крестьянин – землю вспашет, засеет, удобрения подкинет когда надо. А вот требовать гарантий урожая с него смысла нет – слишком много зависит от погодных условий (погреет ли Яндекс-красно-солнышко).
Единственное, что остается заказчику – подбирать более опытных крестьян. А лучше колхоз. И смотреть на предыдущие урожаи (портфолио).
И еще один любимый мною пример. Все смотрели передачу «Тачки на прокачку» на MTV, где делают тюнинг старым авто? Так вот так же и с сайтом – оптимизатор может его прокачать, форсировать движок, а попадет ли машина (сайт) в гонке в топ10 – какие тут гарантии?

Теперь собственно, договор. Некоторые пункты прокомментирую ниже.

Здравствуйте! За последние несколько дней появилось несколько заметок по поводу договоров на создание сайтов, а кто то предложил свои договора, (я например). Естественно все находят какие-то недочёты друг у друга. У меня есть предложение к общественности — давайте попробуем сделать свой хабра-договор совместными усилиями. Предлагаю высказать в комментариях к этому топику свои пожелания по поводу того что должен или не должен включать в себя договор. После чего попробуем оформить всё это в один единый договор и опубликовать его здесь.
Думаю что для многих людей было бы полезно иметь хороший договор, что бы в будущем не наломать дров. Возможно кто то выскажется от имени клиентов, думаю им это тоже было бы полезно.