Из стати вы узнаете о понятии «Жизненный цикл ПО». Мы рассмотрим все этапы этого цикла, но более подробно поговорим об эксплуатации ПО. Посмотрим какие проблемы могут возникнуть при эксплуатации и что же есть у них общего.
Подумаем над тем, кто может решить наши проблемы и разберем их достоинства и недостатки.
Статья делает акценты на интернет-магазины, но охватывает и многие другие web-проекты.
Думаю, каждый из нас, хотя бы раз слышал понятие «Жизненный цикл». Это понятие пришло из естественных наук и понемногу осело в машиностроении, а потом уже и в сфере разработки программного обеспечения (далее ПО). Жизненный цикл описывает некую систему от ее зарождения до умирания. В частности:
Жизненный цикл ПО - период времени от решения о создании ПО, до полного его изъятия из эксплуатации.
Пробежимся по основным этапам жизненного цикла ПО.
Без идеи создать что-то, очень трудно создать это что-то.
Нужно понять, а вообще стоит ли заниматься разработкой. В этом несомненно помогут маркетинговые исследования. Но помните слишком детальный анализ не всегда хорошо. Он может занять слишком много сил и времени. Слишком поверхностный анализ, либо его полное отсутствие, с другой стороны, увеличивает риск пролететь мимо цели.
На этом этапе создается основная идеология системы - проектируются ее структура, закладывается основной функционал, разрабатывается интерфейс и прочее.
Как правило на этом этапе делается очень много лишнего, не нужного, а иногда еще и не правильного. И объясняется это очень просто.
Во-первых, исполнитель может не знать бизнес заказчика. Это не позволяет ему предвидеть некоторые мелочи, которые настолько естественны для заказчика, что он забывает о них сказать.
Во-вторых, не умение общаться. Думаю понятно, что два человека смотрят на одну проблему совершенно по разному. Представьте вы заказчик и договорились с исполнителем о какой-то работе. Время бежит и вот настает момент принятия проекта. Приходит исполнитель довольный собой и… Показывает вам совсем не то о чем вы его просили. При этом исполнитель искренне удивляется вашим недовольством. Вот как раз это и называется - не умеют общаться. Вроде договорились, а о казалось, что каждый договорился о своем.
Ну и в-третьих, низкая квалификация исполнителя. Вы должны понимать, что даже обращаясь в «крутые» web-студии вы не защищены от низкой квалификации. Простой пример. Вы пришли в студию заказать сайт. Ребята посчитали объем работ и выставили вам счет из расчета 30% рентабельности проекта. А вы взяли и продавили студию по цене на 25% и еще похвалились перед друзьями. Т. е. рентабельность проекта стала 5%.
Но не факт, что студия откажется от заказа. Она вполне может принять его и выполнить с рентабельностью 30%. Как? Да очень просто - наймет студента.
Вообще тема «продавить по цене» очень остра и ею почему-то многие пользуются не задумываясь. Причем как заказчики, так и исполнители (задирают цену). Я не призываю, к тому что не нужно торговаться. Я лишь хочу чтобы вы подумали вот о чем. Если вы планируете долгосрочное сотрудничество с исполнителем, то на сколько разумно сильно продавливать его по цене. И если вы планирует долгосрочное сотрудничество с заказчиком, то на сколько разумно задирать цены выше потолка?
Тут, кому-то, может показаться все просто - пишем код, интегрируем дизайн.
Но и тут нас поджидают проблемы. Самая главная это низкая квалификация разработчика. Но даже при высокой квалификации, если сроки начнут поджимать, то качество кода снизится. Хотя надо признать, что в целом код будет выше уровнем, чем если изначально за дело взялся совсем новичок.
После разработки системы или части ее, необходимо протестировать, а то ли выполняет система. Разработкой автоматических тестов занимаются в основном только крупные компании и для крупных проектов. В случаи с интернет-магазином мало вероятно что кто-то будет писать тесты. Скорее всего будут тестировать старым дедовским тестом - откроют в браузере и начнут кликать. Глядишь чего найдут, а что-то и пропустят.
Это одномоментное событие. Дернули рубильник и все заработало так как надо. Ну или мы думаем, что так как надо.
Об этом этапе, а точнее о проблемах на нем мы поговорим чуть дальше. Хотя думаю, что предпосылок для понимания проблем уже достаточно.
Или вывод из эксплуатации. В какой-то момент может произойти одно из двух событий:
В первом случаи мы просто выкинем систему на свалку. А вот во втором еще можно побороться - попытаться доработать систему, так чтобы она вновь начала соответствовать предъявляемым требованиям. В худшем случае, мы возьмем из системы все необходимое, добавим новые требования и будем использовать все это как исходные данные для проектирования новой. Старую системы выбросим.
Моя задача как web-программиста как можно дольше проливать этап эксплуатации и откладывать этап утилизации системы.
Вот вы запустили магазин. И первое что начнет происходить - вы начнете притираться к вашей системе. Вы может вдруг понять, что система работает как-то не удобно или к моменту открытия у вас изменился какой-то внутренний бизнес-процесс, а система его не учитывает.
Со временем, вы можете понять, что вам не хватает какого-то функционала - какой-нибудь статистики или отчетов. Возможно вы захотите интегрировать CRM систему или даже разработать свою, пусть простую, но решающую конкретно ваши задачи. Иногда продвиженцы просят дописать для них модуль автогенерации метаданных страниц или что-то в этом роде.
Возможно, заглянув на сайт конкурентов, вы подметите какую-нибудь интересную фишку и захотите видеть ее и у себя на сайте. В эту же группу стоит отнести «модные тенденции». Одно время были популярны различные информеры. На сайтах можно было видеть десятки различных счетчиков статистики и рейтингов. Не так давно были популярны 3D-облака тегов - их и сейчас можно встретить. А еще на заре 2000ых была дикость, на мой взгляд, запускать на сайте в фоне мелодию.
Может сложиться так, что на старте были заложены «не те» технологии. Представьте, вы открыли мега информационный портал, а разрабатывали его как сайт визитку. Или может сказаться рост проекта - вы открывали блог, а он перерос в тематический портал. Так же в эту группу стоит отнести новые технологии - не исключено, что вы захотите использовать их в своем проекте.
В один прекрасный день сайт может начать тормозить. Причины могут быть разными, но как правило это рост базы данных и рост числа посетителей. Что с этим делать это тема отдельной статьи и здесь ее затрагивать мы не будем.
Еще один не мало важный момент - изменения законодательства. Очень давно муссируется законопроект о СМИ и блогерах, согласно которому нужно будет вести логи поведения всех ваших посетителей. Вести логи не трудно, но это будет дорого - ресурсы то не бесплатные.
Если посмотреть на все что мы перечислили ранее, то становится ясно, что все они приводят к изменению требований к системе, а значит приближают проект к этапу утилизации. А как мы знаем у нас в этом случаи два пути - проектировать новую систему или доработать старую.
Для начала рассмотрим, что такое доработка и как она проходит. Это поможет нам оценить достоинства и недостатки тех людей, которые будут решать ваши проблемы.
Доработка ПО - это некий процесс изменения архитектуры и/или логики системы с целью приведение ее в соответствие с новыми требованиями.
Давайте взглянем на жизненный цикл доработки.
Начинаем мы с какой-то идеи по внедрению чего-либо или же с существующей проблемы, которую надо решить.
По сути дела это этап проектирования. Мы должны четко сформулировать, чего же мы хотим сделать.
Пишем код.
Проверяем на соответствие с поставленной задачей.
Сдаем задачу заказчику. Радуемся, что смогли отложить утилизацию системы.
Этапы 2, 3 и 4 (Формализация ТЗ, Разработка и Тестирование) должны контролироваться кем-то по срокам и по объему. Такого человека называют проект-менеджером. А сам процесс - управление проектом. Этот момент пригодится нам при дальнейшей оценке исполнителей.
Представим, что вы столкнулись с некой проблемой, которая изменила ваши требования к вашему интеренет-магазину. Вы решили справиться с проблемой путем доработки системы. В этом случаи вы можете обратиться к следующим людям:
Рассмотрим каждого из исполнителей.
Считается, что программист в штате это самый надежный способ. Нет утечек информации, всегда рядом и всегда можно проверить, что и как.
Считается дешевым. Платить надо только зарплату.
Потеря квалификации. Мало вероятно, что вы сможете обеспечить 100% занятость программиста только работами над магазином. Разве что сам проект это предполагает. В противном случаи он начнет сидеть без дала, а зарплату то платить ему надо. Вот он начинает настраивать почту, потом заправлять принтеры, дальше еще что-нибудь. В какой-то момент может сложиться парадоксальная ситуация, когда программисту не будет хватать времени заниматься вашим сайтом. Тогда придется нанять еще одного, а так глядишь еще чуть-чуть и можно будет открыть web-студию.
В качестве нагрузки сверху, вам придется заниматься еще и управлением проектом. Т. е. вы должны будете формализовать ТЗ и контролировать сроки исполнения задач. Если у вас не будет на это время, то придется опять-таки нанять для этого отдельного сотрудника. Что я говорил про открытие web-студии?
Самый большой минус - увольнение программиста. Как правило разработчики народ ленивый и документацию писать не любят. И вот единственный сотрудник, который знал как работает система, что он в ней изменил и что еще нужно будет изменить, уходит. На его место приходит новичок и теряет время на то чтобы понять как работает система со всеми ее видоизменениями.
Первое, что нужно сделать, если вы хотите нанять программиста, это хорошенько подумать. Если у вас нет постоянного потока задач, то в перспективе лучше обратиться к другим исполнителям.
Если у вас есть постоянный поток задач, то можно подумать о том чтобы взять программиста в компаньоны. Так можно существенно повысить производительность труда, а так же снять с себя техническую часть проекта. Но помните, партнеров надо выбирать очень аккуратно.
Если вы программист, то надо тоже очень сильно подумать, а стоит ли идти в проект. Если интернет-магазин не предполагает постоянны поток задач, то лучше устроиться в web-студию. Хотя бы потому что там ваша квалификация будет расти.
Постоянно отслеживайте объем поступающих к вам задач. Как только задачи начнут иссякать - задумайтесь о своем будущем, вероятнее всего скоро придется искать новую работу.
Самый очевидный плюс - их много. Их на столько много, что можно на проект привлекать хоть каждый день нового.
А раз их много, то соответственно это очень дешево.
Фрилансер - это один человек во всех лицах. Он и менеджер заказов, и управляющий проектом и разработчик. Я когда тоже занимался фрилансе, да и сейчас иногда беру проекты. По своему опыту скажу, когда я понял, что у меня проблемы с управлением проектами, у меня была примерна следующая статистика - 70% управление, 30% разработка. Тем что приносит мне деньги я занимался всего лишь 30%, и то что обслуживает этот процесс 70%. Тогда я очень сильно занялся изучением проблемы личной эффективности, управлением проектами и тайм-менджментом. Я смог вытянуть статистику до 25% управления и 75% разработки.
Очень часто первым минусом я слышу, то что он может пропасть. Вот как раз пропасть он может по причине, что он занят всем.
Последний минус - это в среднем низкое качество кода. Как правило фрилансем начинают заниматься студенты, которые только-только начали программировать и им кажется, что они уже знают и могут все. И таких очень много. Настоящие спецы, которые есть среди фрилансеров, это лишь небольшая доля на фоне моря новичков.
Если решили нанять фрилансера, то помните следующее. Обязательно заключайте договор. Вероятнее всего фрилансер выступает как физ. лицо. Они редко организовывают ИП или юр. лицо, а значит договор будет классифицироваться как договор общегражданской ответственности. При этом вы будете налоговым агентом для фрилансера, а это ФНС (НДФЛ), ФСС (обязательное медицинское страхование) и ПФР (пенсионные отчисления).
На старте проекта обговорите контрольные точки и контролируйте выполнение задач по ним. Так вы убережете себя от того что ваш проект будет делаться в последнюю ночь перед сдачей.
Заключайте договора. Помните о ФНС, ФСС и ПФР.
Изучайте тайм-менеджмент и управление проектами.
Подумайте об открытии ИП или юр. лица. Это не так уж и страшно, как кажется.
Если вдруг решили слиться с проекта, то позвоните заказчику. Даже если вы не измените условий проекта, то расстанетесь как взрослые люди.
В среднем высокое качество кода. В студиях каждый программист работает на десятками проектов в год. Он постоянно видит разные технологии и алгоритмы. Постоянно растет квалификация.
Задачи, как правило, сдаются в срок. Обычно в штате студии есть проект-менеджер.
Надежно. Студии более ответственно относятся к договорам и не будут вести внутренний саботаж, как это может делать программист в штате.
Основной минус это стоимость работ. Цена однозначно выше ценника фрилансера, но, все же, в перспективе может оказаться дешевле чем программист в штате.