Тематические статьи →

Процессы веб-разработки, которые не очень заметны, но существенно влияют на качество полученного результата

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

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

Неяв­ные работы

Наи­бо­лее часто сле­ду­ю­щие про­цессы кажутся «ненуж­ными»:

  • Фор­ма­ли­за­ция ТЗ. Заказ­чикам ПО не все­гда оче­вид­но, что без нормального ТЗ про­сто нельзя создать про­дукт, кото­рый будет в доста­точ­ной мере соответствовать ожи­да­ни­ям. При этом, состав­ле­ние хоро­шего ТЗ — это слож­ный про­цесс, кото­рый тре­бует суще­ствен­ных затрат вре­мени высо­ко­ква­ли­фи­ци­ро­ванн­ных спе­ци­а­ли­стов. ТЗ должно быть одно­вре­менно и понят­ным всем сто­ро­нам, и реа­ли­зу­е­мым. Именно поэтому его раз­ра­ботка тре­бует уча­стия всей команды про­ек­та.
  • Про­ек­ти­ро­ва­ние и прототипирование. Продумывание архи­тек­ту­ры, созда­ние графических скетчей, раз­ра­ботка программных прототипов — это про­цессы, необ­хо­ди­мость кото­рых не все­гда оче­видна для Заказ­чи­ка, а объём полу­чен­ных резуль­та­тов по этим рабо­там обычно кажется незна­чи­тель­ным отно­си­тельно затрат на их выпол­не­ние. При этом необ­хо­ди­мость про­ек­ти­ро­ва­ния обос­но­ва­на: раз­ра­ботка без деталь­ного про­ду­мы­ва­ния спо­со­бов реа­ли­за­ции обычно при­во­дит в тупик или к созда­нию немас­шта­би­ру­е­мых реше­ний. А не очень боль­шой объём резуль­та­тов «на выходе» объ­яс­ня­ется очень про­сто — очень много сге­не­ри­ро­ван­ных на этом этапе идей и раз­ра­бо­тан­ных материалов отбраковываются.
  • Тести­ро­ва­ние. Необ­хо­ди­мость про­верки про­грамм­ного про­дукта обычно не вызы­вает вопро­сов, а вот выгоды авто­ма­ти­за­ции этого про­цесса редко бывают оче­вид­ны­ми. Неболь­шие про­екты могут быть успешно и в пол­ном объёме протестированы вручную за несколько часов, так зачем тра­тить десятки часов на авто­ма­ти­за­цию этого про­цесса? Объ­яс­не­ние очень про­стое — если пла­ни­ру­ется даль­ней­шее раз­ви­тие про­ек­та, то про­цесс тести­ро­ва­ния будет повто­ряться десятки и сотни раз, а в таком слу­чае суммарные затраты на руч­ное тести­ро­ва­ние соста­вят не «пару» часов, а уже сот­ни. И авто­ма­ти­че­ское тести­ро­ва­ние сразу ста­но­вится эко­но­ми­че­ски обос­но­ван­ным.
  • Рефак­то­ринг. Рефак­то­ринг — это про­цесс «пере­де­лы­ва­ния» изна­чально создан­ного про­грамм­ного про­дукта с целью опти­ми­за­ции тех или иных пока­за­те­лей. Как пра­ви­ло, рефак­то­ринг направ­лен на повы­ше­ние сопро­вож­да­е­мо­сти и быстродействия. Обу­слов­лен это про­цесс тем, что про­сто невозможно создать слож­ный про­грамм­ный про­дукт, кото­рый сразу и функ­ци­о­ни­рует пра­виль­но, и код его «кра­си­вый», и ско­рость работы высо­кая. Поэтому боль­шая часть про­ек­тов реа­ли­зу­ется в несколько захо­дов: «чтобы рабо­тало», «чтобы было кра­сиво» и «чтобы рабо­тало быстро».
  • Сопро­вож­де­ние. Очень рас­про­странён­ное заблуж­де­ние — это вера в воз­мож­ность созда­ния «веч­ного дви­га­теля», то есть про­грамм­ного про­дукта, кото­рый будет отлично работать дол­гие годы без какого-либо даль­ней­шего сопро­вож­де­ния со сто­роны раз­ра­бот­чи­ков, системных администраторов и самого Заказ­чи­ка. Очень незна­чи­тель­ная часть Заказ­чи­ков ПО пони­ма­ет, что пер­вич­ная раз­ра­ботка ПО — это только начало жиз­нен­ного цикла про­дукта, в про­цессе экс­плу­а­та­ции все­гда будет необ­хо­ди­мость что-то делать.

Разу­ме­ет­ся, что никто не про­тив выпол­не­ния этих про­цессов, покуда они не опла­чи­ва­ются из бюд­жета про­ек­та. Но так, конеч­но, не быва­ет, если мы рас­смат­ри­ваем про­фес­си­о­наль­ную ком­мер­че­скую разработку. За любые выпол­ня­е­мые работы Заказчик все­гда платит: раз­ра­ботка про­грамм­ного обеспечения — это биз­нес, любые «бес­платно» стоит интер­пре­ти­ро­вать как «уже вклю­чено в сто­и­мость». Это очень банально и логич­но, однако вера в суще­ство­ва­ние «бес­платного» настолько рас­про­стра­не­на, что сложно не напи­сать об этом.

Но можно этого и не делать. Если Вас не инте­ре­сует резуль­тат. Михаил Жва­нец­кий

Вари­ант, что можно не выпол­нять отдель­ные работы и при этом про­ект не постра­да­ет, мы рассматривать не будем, так как это уже «из обла­сти фан­та­стики».

Осме­чи­ва­ние работ по веб-раз­ра­ботке

Если про­цесс запла­ни­ро­ван, то его сто­и­мость будет отра­жена в смете или в явном виде, или в виде неотъ­ем­ле­мой части дру­гих работ. И тут возможны 3 ситу­а­ции:

  1. Про­цессы запла­ни­ро­ваны и ука­заны в смете в явном виде. Иногда это вызы­вает оттор­же­ние у Заказ­чи­ков, осо­бенно если смысл про­цессов непонятен. Если диа­лог кон­струк­ти­вен, то боль­шая часть подобных возражений «сни­ма­ется» после разъ­яс­не­ния целей про­цессов.
  2. Про­цессы запла­ни­ро­ваны, но их сто­и­мость заложена в другие работы, кото­рые обладают более оче­вид­ными резуль­та­тами выпол­не­ния. Тут воз­ни­кает дру­гая про­блема — сто­и­мость работ, в кото­рые зало­жены неяв­ные про­цессы, воз­рас­та­ет, а если имеет место сравнение цен несколь­ких постав­щи­ков дан­ных услуг, то это сравнение уже не в пользу постав­щи­ка, кото­рый изна­чально закла­ды­вает все нужные про­цессы в сме­ту.
  3. Про­цессы не запла­ни­ро­ваны и их сто­и­мость в бюд­жет не зало­же­но. В резуль­тате вышеописанные про­цессы либо не будут выпол­нятся вовсе (это часто при­во­дит к про­валу про­екта), либо их выпол­не­ние «неожи­данно» ста­нет необ­хо­ди­мым уже по ходу реа­ли­за­ции, то есть потре­бует пере­со­гла­со­ва­ния бюд­жета и сро­ков в сторону увеличения.

На рынке имеют место все три под­хода.

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

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

Воспользуйтесь нашими
знаниями и опытом

Отправьте нам сообщение при помощи формы. Или напишите на e-mail s@web-creator.ru

Мы максимально оперативно ответим Вам по электронной почте или перезвоним.

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

Либо просто позвоните нам по номеру: +7 495 215-1501

Мы работаем по будним дням с 10 до 19 часов.

Комплексные услуги

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