Всем привет!

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

Под термином в названии статьи «внедрение «под ключ»» подразумевается поставка и внедрение ERP-системы в полном соответствии с ожиданиями и требованиями клиента.

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

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



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

Вы PM. Как узнать – готова ли вёрстка к реальному использованию?
Вы заказчик. Как убедиться, что работа выполнена качественно?

Когда я стал тим-лидом, а позже PM, передо мной стала задача проверять вёрстку наших проектов. Нужно было выработать формальные, легкопроверяемые критерии, соответствие кода которым, должно было давать некую гарантию, что не будет факапов и ни клиент, ни программеры не сказажут потом “WTF?”.

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

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

Итак что же это за список?
UPD: 2011/06/15 — добавил пояснения какие ошибки валидации допустимы.

1. Верстка, аутсорсинг и технические задания

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

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

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

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

Куда применить домен.РФ?

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

1) Прежде всего нужно понимать, что домен.РФ – это решение нишевое и ситуационное. Вряд ли компании будут использовать его как основной официальный домен своего сайта. Домен.РФ удобно применять в каких-то особых условиях, когда необходима быстрая запоминаемость или краткость. Например, в каких-то специальных рекламных акциях или на рекламных носителях определенного рода, таких как рекламные щиты вдоль загородных дорог.



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

Я программист и периодически мне попадаются заказчики у которых есть какая то идея (схема работы), для сайта/скрипта/приложения, но смысл этой идеи им тяжело сформулировать или просто лень формулировать. Я в таких случаях прошу написать тех. задание (и объясняю как это сделать) после этого, они обижаются и уходят.
А вам попадались такие заказчики?
Как вы с ними общаетесь?

Сегодня попросили оценить стоимость разработки, прислали excel-документ с десятью страницами следующего вида:


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

Кабы схемку, аль чертеж, мы б затеяли вертеж...
(Тит Кузьмич и Фрол Фомич)



Нужно ли ТЗ сайту? Сегодня это один из самых спорных вопросов веб-разработки.

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

Но если сайт, в техническом плане, вполне обыкновенный, и объем не слишком… Как здесь быть?