Скорость и дешевая разработка ПО

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

Остается понять, как же разработчик может снизить цену?

Например использование неких уже готовых решений. Для сайтов использование уже написанных CMS, при этом дизайн к сайту тоже легко можно купить, благо студий занимающихся разработкой дизайна для сайтов очень много, есть больший сайты на которых дизайн можно купить за 60-100$ с уже готовой версткой даже под Вашу CMS, что несомненно сокращает время разработки. Разработчики клиентских приложений так же могут использовать некие шаблоны или готовые решения для основных необходимых возможностей.

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

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

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

Скорость и дешевая разработка ПО site:maiseyeu-ihor.blogspot.com

Мы пользуемся внешними поисковыми системами заместо того, чтобы просто использовать то, что есть на сайте. Это связано не только с тем, что большие поисковики лучше. Часто это связано с тем, что контент на сайте просто не индексируется внутренней поисковой системой потому что для данного контента просто не было написано модуля, который бы правильно индексировал её. Тут все просто. Заказчик видит всегда то, что лежит на поверхности, но не видит того, что внутри, он видит сайт, но не знает как он работает и не может знать верно ли работет индексация информации на сайте? Она может и не работать совсем, тогда строка "ПОИСК" просто выполняет роль некого элемента дизайна, не более. И опять же разработчика мы не можем винить в этом. Поиск это дополнительная работа и дополнительное время. Он просто отработал свои деньги, а за просто так работать никто не будет. Все люди и все хоятят кушать.

Это мои выводы по поводу скоростей и дешевой оплаты труда. Я думаю тут можно привести еще не один довод как в одну сторону так и в другую.

Спешка в разработке ПО. Оправданный шаг?

Я думаю, почти каждый разработчик ПО работая в огромной компании, маленькой фирме или просто работая сам на себя сталкивался с ситуацией, когда заказчику вот срочно нужен результат. Ничего не готово идет процесс проектирования, есть куча рисунков классов их связи между собой, но больше ничего. И ЭТО нельзя показать! Заказчик не поймет, что ведется работа, ему нужен результат, а не схемки и графики, а не написанные библиотеки в которых ютиться логика всего того, что он хотел. Ему нужно видеть, для него есть только то, что он видит и ничего больше. И вот как с этим бороться?

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

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

Осталось понять, как это все объяснить заказчику?

Изменение ТЗ во время разработки приложения

Я думаю многие разработчики сталкивались с такой бедой как изменение технического задания при разработке сайта или программы во время разработки приложения. Такое есть и, наверное, будет всегда. Да это плохо и часто губительно, но ничего не поделаешь. Так повелось, что заказчики никогда толком и не могут определить, что же они хотят? "Вот эту фишаЧку, или вот эту!" И что делать нам разработчикам? Хочешь заработать свою копейку делай, переделывай, строй, разрабатывай. Да, за лишнюю работу цена увеличивается, но часто бывает, что и не рад увеличению этой самой платы так как работы бывает много.

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

Нужна ли спецификация для проекта?

Когда-то все свои программы я писал даже не думая о том, чтобы составить хотя бы перечень из функциональностей доступных в программе. Программы писались и даже работали =) да вот только бывало, что работа над одной программой занимала огромное количество времени. И это происходило не из-за того, что программы были огромными и многофункциональными. Нет, скорее наоборот! Они были маленькие и их функциональность была смехотворна. Тогда почему же их разработка занимала много времени? Все просто! У меня небыло и малейшего плана разработки, я не задумывался о взаимодействиях одной части программы со второй.

Это было просто ужасно, так как простейшие часики с настройками, будильником, напоминалками и календарем занял полторы тысячи строк. Подумайте 1500 строк на часы, которые ничего из себя не представляли. Но не только это было причиной таких больших сроков разработки. Порой программа выходила только через несколько версий, т.е. я начинал писать с версии 1.0, а свет увидела только 1.4 =(( И все потому, что напортачив в коде, я не разбираясь начинал писать новую версию, уже более продуманную.

И все-таки, как можно было исправить это плачевное положение? Я думаю каждый программист, который сталкивался с такими проблемами уже знает ответ на этот вопрос. А может кто-то уже и использует, то про что многие знают но мало кто использует, так как считают не нужным. А зря.

Итак, мой разговор пойдет, об одной из частей разработки программного обеспечения - написании спецификации.

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

Так, какую информацию можно изложить в спецификации? Наверное, самое главное это указать, полностью всю функциональность разрабатываемого приложения и определить как должен с каждой из них работать пользователь! Это очень важно, так как на этом шаге мы становимся на место пользователя и пытаемся разобраться как и что будет работать. Часто бывает, что разработчики создав приложение даже не думали как с ним будет работать пользователь. И для того, чтобы пользователю воспользоваться какой либо функциональность приложения ему приходится совершить чудеса эрудиции и свои превосходные знания компьютера. НО!

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

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

Допустим, мы написали о писали всю функциональность приложения и написали как со всем этим будет работать пользователь. Можно ли расширить и добавить в нашу спецификацию какую-нибудь информацию, которая может помочь при программировании? Конечно можем. Этот шаг мало кто делает (я сам так сделал только один раз =)) ) но польза от следующего действия огромна и позволяет сократить время программирования в 2 и более раз. Что это за шаг? Шаг разработки внутренней структуры самого приложения. Т.е. для каждой описанной нами ранее функциональности мы описываем из чего она будет состоять программно. Т.е. классы и для чего они нужны, взаимодействия между классами. После этого действия у нас все приложение будет уже описано, нам только останется создать все эти классы, а именно создать реализацию каждого конкретного класса, их методы.

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