Drum Boom

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

Я почти никогда не снижаю стоимость работ за счёт снижения прибыли - при нынешнем рынке - это бесцельная трата ресурсов. Вместе с тем, как я уже говорил выше - есть случаи, когда стоимость можно снизить за счёт того, что клиенту часть функционала просто не нужна и была навязана по неизвестным причинам.

Буду здесь краток и перечислю какие средства я здесь использую:

• Microsoft Project
• Mozilla Sunbird 0.8 RU
• Календарик Google
• WEBASYST
• ОДНА из CRM (маленький обзор сделаю в конце статьи)

Итак всё спланировано, с заказчиком утверждена задача , которая разбита на временной график и начинается работа.

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

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

Теперь о некоторых средствах:

• HiTask - система онлайн управления задачами и проектами - неплохо, и интерфейс приятный.
• TODOIST - больше подходит для персонального серьёзного органайзера.
• Online Task List - хороший сервис управления задачами, с большим колличеством функций

Используя эти вещи, вы сможете более эффективно управлять задачами и контроллировать их исполнение, но основная часть успеха работ - зависит от вас.

Также можно использовать какой нибудь хелпдеск (HelpDESK) для общения с клиентом и тестировщиками.

Но самым злободневным вопросом в процессе разработки является всё-таки синхронизация работы и возможность одновременной и параллельной работы членов команды.

Перед тем как углубляться в инструментарий - объясню суть проблемы ибо она состоит из нескольких:

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

Итак, для управления файлами я рекомендую предусмотреть документ регламентирующий создание файлов в проекте и  прописать изначальную структуру директорий. К примеру, для простого проекта сайта состоящего исключительно из html предусмотреть каким образом будет складываться структура файлов и каким образом будут указываться названия для файлов и папок. К примеру за основыу берём утверждение что все категории у нас оформляются в алфавитном порядке и для каждой новой категории указывается индекс типа int, соответствующий порядку категории то есть в корне у нас будет располагаться index.htm и папки 1, 2, 3 и так далее (это не всегда удобно -  поэтому я привожу такие правила лишь для примера), названия файлов в категории будут называться index.html для главной страницы категории и 1.html, 2.htm, 3.html и так далее. Кроме этого скрипты javascript будут оформленны в дирректории JS а таблицы стилей в папке CSS. Вот очень грубый, но я думаю, что понятный пример такого документа.

Далее уточним систему построения модулей.

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

Предусмотреть шаблонизацию и её правила, как на основе ядра, так и в рамках отдельных модулей и подсистем, к примеру применить СМАРТИ - технологию, если она поддерживается языком программирования. (Если что ищите в Гугле Smarty )

Для css желательно сделать базовое описание стилей или как оно правильно называется Guide Style. Это будет тоже очень хорошо.

Для управления самими файлами в процессе разработки рекомендую средства SVN (CVS) или Subversion, которые смогут привести ваш проект в порядок и упростить процесс билда и предбилдовой подготовки. Что это такое? Это изобретение человечества представляет собой репозиторий или несколько вашего проекта, он даёт возможность управлять изменениями в файлах и регистрировать новые файлы, таким образом, чтобы ни один файл проекта не был утерян. На сегодняшний день меется возможность установить репозиторий SVN у себя на машине, на сервере или вообще воспользоваться бесплатными или платными репозиториями в сети. Примеры таких репозиториев:

• http://sourceforge.net
• http://svn.berlios.de/wsvn
• Google Code
• http://assembla.com и другие...

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

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

Подробнее о средствах SVN читайте здесь>>

Также SVN в той или иной мере реализованы в некоторых CRM, ориентированных на разработку.

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

А может и вовсе без документации обойтись? Так будет быстрее и проект закончим раньше. да и не нужна она нам, всё равно тут всё просто и ясно и разобраться не сложно будет?

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

С этим выяснили - документация нужна.

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

Я пользуюсь такой технологией . Делаю самодокументирующийся код путём вставления комментариев по каждой операции, а потом на основе этого - выстраиваю документацию автодокументатором, к примеру для php PHPDOCUMENTER или suttree

Хотите найти другие средства документирования - пожалуйста - на любой, опять же, вкус

Вот для PHP

Вот для Javascript (не очень много, но что поделаешь - специфика учитывается)

Таким образом можно найти средства для документирования под любой проект - проверял - получилось.

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

Про управление инцидентами и сообщениями я говорить второй раз не стану - я уже упоминал о таких средствах в первой части статьи, когда говорил о системах класса CRM/ERP/HEPLDESK и других им подобных и основанных на ITIL- прочтите внимательно - будет счастье.

Заключение

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

А теперь ещё раз пройдусь по моим самым любимым CRM и ERP решениям:

• SugarCRM - система в основном ориентирована на продажи и маркетинг, но тем не менее может быть использована и в IT отрасли. Отличительная черта - огромный функционал и удобство. Бесплатная.
• TUTOS - одна из лидеров бесплатных систем управления на российском рынке. Достаточно легко приспособить под любые нужды.
• Apache OFBiz - сиcтема с огромным набором функций написанная на Java. Хороша для организации виртуального офиса.
  Compiere ERP + CRM Business Solution- для производства, учёта, оказания услуг и др. функций управления и бизнеса - сочетает в себе функционал ERP и CRM системы, что очень полезно. Может быть интегрирована с собственными наработками на тему - это удобно.
  ]project-open[- отличное решение для полного покрытия всех учасков деятельности средней и малой IT компании, предназначена как для реселлеров и внедренцев, так и для производителей софта.

Ну и пожалуй остальное и как всегда на свой вкус вы найдёте здесь.

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

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

Если вас занитересовала данная статья и вы хотели бы внедрить такую систему на предприятии - могу помочь вам в качестве разработчика, внедренца, интегратора или консультанта в области решений для бизнеса. Чтобы связаться со мной - пользуйтесь формой обратной связи или адрессом drumboom.net{собачка}gmail.com

Удачи Вам и процветания.
С уважением,
Ваш Друм Бум

Страницы: 1 2