Управление проектами *

Уважаемый пользователь 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 – какие тут гарантии?

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

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

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

Приглашаем участвовать в первой международной конференции PM Days 2008.

Главное отличие PM Days — что она создана менеджерами для менеджеров и Вам не придется полдня слушать как хорошо внедрять продукт компании X..Z. Обсудим как реально драйвить команды, использовать факапы по назначению :-) И многое другое…

Формат конференции предусматривает — что любой участник может стать докладчиком на флипчарте c интересной темой!

• Управление ресурсами.
  — Сколько у меня свободных специалистов — как определить? Смогу ли я потянуть новый проект?
  — Последствия неудачного управления ресурсами — срыв сроков, падение качества (в погоне за сроками).
• Краткий курс человековедения для ИТ менеджера
  
  — Что мешает работать вашим людям?
  — 6 вещей, который программисты не любят.
  — И 6 вещей, которые программисты любят.
  — Удержание и мотивация программистов
  — Основные ошибки российских менеджеров
  — Культурные различия (США, Китай, Индия).
  
• Инструменты управления проектами, требованиями, задачами.
  
  — Microsoft Project, Jira и т.п. Что реально работает? Примеры, кейсы?
• Управление аутсорсингом веб-разработки
  
  Управление коллективами веб-разработчиков, верстальщиков и пр. в регионах
  — Какие преимущества такой схемы (легкое масштабирование — набор и сокращение команды), экономия затрат?
  — Какие затраты уменьшаются (аренда офиса), а какие — возрастают (управленческие)?
  — Каким компаниям и на каком участке работы выгодны удаленные команды?
  — Факторы успеха в управлении удаленными командами?
  — Какие риски наиболее велики при управлении командами?
• Эффективное управление корпоративными интернет-проектами
  
  — Какими процессами управляет менеджер корпоративного интернет-проекта?
  — Веб-разработка, Проектирование, Контекстная реклама, Поисковое продвижение
  — Управленческие фукнции: формулирование целей, оценка деятельности, контроль выполнения.
• SLA (Service Level Agreement) или как правильно зарабатывать на поддержке.
  
  — Перечень услуг, предоставляемых в рамках договора поддержки (консультирование по новым функциям, управление и трекинг задач
  — Cоздание и поддержка тестового сервера
  — Обеспечение непрерывности функционирования объектов, регулярное резервное копирование, тестирование.
  — Критерии (измеряемые) качества этих услуг, например в течение 2 часов от начала поступления задачи в систему менеджер должен обновить ее статус.

Приглашаем интересных докладчиков!

Приглашаем менеджеров WEB-проектов, тимлидов и ИТ-директоров для
участия

Только что спас человека :-) Точнее, небольшую студию из Украины. Судя по содержанию нашей с ними беседы, для небольших, начинающих компаний нижеследующие слова будут актуальны:

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

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

В договоре на создание сайта надо прописать, что создание контента и наполнение (внесение на сайт) туда не входит. И при разговоре заставить клиента обратить на это внимание.

Предлагаю угадать почему ;-)

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

р

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

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

По опыту студий, в которых я работал, а также по опыту наших коллег, мы составили шит-лист того, что говорят такие «заказчики»:

1. У нас поменялись приоритеты, проект отложен на неопределенное время. Мы вам обязательно позвоним, будьте в полной готовности.
   
   

Цель данной заметки (или конспекта) — предложить строгим (но конструктивным :-) критикам перечень группы требований и способы их структурирования, предъявляемых к коммерческому корпоративному сайту. Планируемый жизненный цикл сего текста — сначала она будет доступна только участникам соответствующего блога. Затем, всем. Так что спешите критиковать.
Эти требования важно предусмотреть при проектировании сайта, и задокументировать в концепции сайта и техническом задании на проект. Публикация не претендует на полноту и завершенность, однако вместе мы сможем ее приблизить к идеалу.

Задачи аналитика при проектировании сайта

Кто в проекте работает с требованиями? Бизнес-аналитик. Однако, на малых проектах его функцию выполняют технические директора, директора по разработке, менеджеры проектов. Задачи аналитика:

1. Идентифицировать все источники требований
2. Выявить требований (часть требований существует, но клиент их не всегда осознает — в этом поможет опыт аналитика по веб-проектам)
3. Сформулировать требования и уточнить их
4. Назначить приоритет требованиям.
5. Сформулировать технические задания

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

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

В связи с этим решил заняться своим собственным Time Management-ом. Так как знаний у меня в этой области явно было мало, решил почитать некоторые книги. Первой книгой, которая попала ко мне в руки, точнее, попала в мой наладонник – была “Getting Things Done” David Allen. Буквально первые же главы этой книги, заставили задуматься меня над темой этого поста.

В комментариях к статье "Миф о средней цене на сайт" человек, который попытался приписать мне «неуважение к конкурентам», а заодно подверг сомнению некоторые факты:

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

Меня тут спросили: «Как вы мешаете лицам, указанным в договоре, представлять мнение завхоза и главного инженера как свое собственное». Мы не мешаем им. Но договор, тем не менее, сильно нам помогает. Поясню как.