Заказчик VS Программисты.

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

1. Техническое задание (ТЗ)
Это первый и очень важный этап, к нему стоит отнестись наиболее серьезно, иначе можно пустить все на самотек и получить в итоге головную боль и полную чушь за ваши деньги. Если вы не разбираетесь в программировании и разработке хотя бы чего-то похожего, то лучше вам не браться за написание. Но сразу обращаться к исполнителям тоже не имеет смысла.
 
Я хочу предложить вам другой вариант, на мой взгляд более продуктивный. Вам нужно найти одного хорошего специалиста, который хорошо владеет теорией баз данных, программирования и всего что прилагается (Apach, Unix/Windows  и т.п.). То есть это хороший специалист, который поможет вам написать ТЗ, оформить его и привести в четкий понятный исполнителям вид. Во-первых, вы сможете разрешить много вопросов, которые для вас были не до конца ясны. Причем с человеком, который будет только писать, а ничего делать не будет. Ему так или иначе меньше смысла придумывать более удобные для себя  решения (что свойственно исполнителям), взамен более лучших для вас. Во-вторых, вы составите четкий план что делать, стоит потратить на это столько времени сколько нужно, тогда на всех остальных этапах вопросы будут решаться проще — есть куда сослаться. Сослаться и в плане проблем с исполнителями и для того, чтобы не держать все это в голове, все равно не вместится. Сами вы вряд ли напишите не спорное ТЗ, ваше незнание будет работать против вас. Можно еще долго расписывать как и что, но я думаю вы уловили мысль. Этот человек сможет вам помочь и на этапе разработке, если с исполнителями на пол пути начнутся проблемы, он может решить конфликт. Есть ТЗ, есть договор о сумме, если что-то идет не так, то скорее всего это не ваша вина, если вы хорошо все проработано на этом этапе. Это важный человек, стоит не жалеть времени на его поиск.
 
Как искать — это другой вопрос. Ели ваша интуиция и хватка вас не подводят, а намерения четкие — вы его найдете. Или у вас есть хорошие знакомые. Если же нет, не знаю что вам посоветовать как универсальный рецепт, кроме как интересоваться портфолио и/или рекомендациями. Тут все не так просто, говорить могут красиво, а в итоге специалист надежд не оправдает, а поймете вы это поздно.
 
Еще один важный момент, ориентир на расширяемость. Вы можете не вписываться в текущий бюджет, но начать уже стоит сейчас. В ТЗ можно обдумать и описать какой-то функционал, но не давать его исполнителям. Если ваш специалист имеет хороший опыт, то на этом этапе можно на достаточном уровне (для последующего расширения без проблем) обдумать как это будет реализовано.
 
Этот этап требует вашего непосредственного участия, общайтесь со специалистом, обсуждайте какие либо вопросы, спрашивайте что еще можно сделать, интересуйтесь непонятными для вас моментами. Кстати, когда вы обсуждаете это, то тоже делитесь ценным опытом. Как вариант вы можете стать партнерами и получить по копии CMS для вас и для специалиста, пересмотрев оплату исполнителям. На практике этот метод очень хорош, когда вы общаетесь с профессионалом и многие вещи всплывают сами собой. Общаетесь понятное дело конструктивно, по делу.
 
2. Выбор платформы
Выбор платформы тоже стоит отметить, хотя все это решиться после первого пункта довольно просто и решать опять же будете не вы, а человек которого вы нашли.
 
3. Поиск исполнителей
На этом этапе у вас есть четкое ТЗ, что облегчает разработку даже с проблемными исполнителями. У вас будет человек, который поможет вам контролировать процесс и не будет руководителем от команды разработчиков, поэтому будет представлять ваши интересы, а не их. В этом и есть основной плюс такой разработки, в отличии просто от поиска исполнителей. Нет, если сразу искать исполнителей вы тоже разберетесь что и как и как надо было делать сразу, но с большими потерями.
 
4. Сроки
Начинающие программисты всегда занижают сроки, не намеренно, просто они в силу опыта не очень адекватно оценивают свои силы. Опытные программисты тоже не телепаты и все предвидеть не могут, они лучше накинут неделю/месяц, от оптимистического срока. Не советую вам гнаться за сроками, смотрите лучше на то как идет процесс и идет ли нормальная работа над вашим заказом, чем подгонять и сбивать людей с толку. Если на заказ уделяется достаточно времени и подвижки стабильно заметны и существенны, то старайтесь держать все на этом уровне и как заказчик контролировать процесс, но без “забегов на время”. Опоздаете на месяц, ничего не случится, если через месяц ваша разработка не будет актуальной, задумайтесь не зря ли вы вообще все это начали.
 
5. Документация
Документация состоит из нескольких частей.
 
  • руководство пользователя, тут скорее всего достаточно будет общих моментов (или моментов, где есть технические ньюансы, которые вам могут быть непонятны) т.к. на этапе составления ТЗ (обдуманного и с вашим активным участием) вам уже многое будет ясно в плане работы с CMS
  • комментарии в коде, достаточные для того, чтобы другой разработчик мог сориентироваться в нем без лишних проблем, вполне возможно потом вы будете улучшать вашу систему и это потребуется. Контролировать это вам так же поможет специалист из первого пункта
  • описание структуры файлов/каталогов
  • описание системных требования (все версии, дополнительное ПО, если система его использует и подобное)


6. Тестирование
Тестирование — это по сути сдача проекта разработчиками. Проверьте весь функционал, не обязательно включать в ТЗ заполнение примером, заполните сами. Получите опыт общения со своей системой, сразу увидите если что-то не так. Сверяемся с ТЗ при необходимости, все проверяем что куда и как.
 
Возможные проблемы и их решение
Я не зря говорил вам о подходе к написнаию ТЗ, множества проблем можно избежать на этом этапе. Начиная от неверного понимания ваших задач, до использования вашего доверия разработчиками. Все проблемы с контролем работ и тестированием вам поможет оценить специалист которого вы наняли/договорились на каких либо условиях.Это и есть основа, большинство проблем по разработке решается именно так, я не учитываю человеческий фактор (кто его знает как он себя проявит) и другие мелочи т.е. пишу вам как программист, а не как заказчик и описываю другую сторону разработки. Другая — это значит, что я бы без проблем сделал по готовому ТЗ за адекватную сумму какой либо продукт, а общаться гораздо проще и практичнее со специалистом чем с ничего не понимающим заказчиком. Тогда по сути на исоплнителя ложится задча — напистаь ТЗ и все головняки связанные с этим, а не факт что он к этому готов.
 
Еще варианты реализации

Помимо разработки всего с нуля, не считая наработок исполнителей, есть еще один варинт. Это взять за основу готовую CMS и расширить ее возможности. Вариант неплохой, но у него есть минусы:
 
  • Все не исправленные уязвимости и ошибки теперь полностью принадлежат вам
  • Держаться придется в рамках структуры этой CMS, ее принципов работы (хотя тут все зависит от того как вы выбирали)
  • Сделать хороший анализ и выбрать действительно подходящую CMS, которая сэкономит время и деньги, а не добавит проблем и не растянет разработку очень непросто
 
А в качестве плюса — экономия денег и времени на реализации стандартных модулей. Тут все зависит в большей степени от того, есть ли подходящий под ваши условия продукт на рынке, если да -то вы вероятно быстро его найдете и разберетесь. Если нет, то поиски и выбор затянутся неизвестно насколько. Лично мне этот вариант не нравится, из-за сложностей с поиском и анализом готовых решений.
 
В ообщем пост о том, что все решаемо, если к задаче правильно подойти, даже если подобных разработок нет или оди сильно ограничены по функционалу — это не проблема.

1 комментарий

avatar
Не со всем согласен. И вообще не совсем понятно название статьи в совокупности с самой статьей.
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.