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

Немного о себе

Я фронтенд-разработчик, ментор и делаю сайты на Angular за деньги вот уже 5 лет. Работал на фрилансе, в крупных компаниях и в стартапах. Помимо основной работы я завершил 8 сторонних проектов. Те ошибки, что я допустил, стали основой для этой статьи.

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

Договор

В идеале - да, но это не предмет этой статьи. Договор - беспроигрышный вариант, когда вы делаете что-то за деньги. Но мы же все таки хотим просто помочь кому-то, не так ли? Представьте, что вы попросили хорошего друга помочь с каким-то непростым делом, а он вам вместо “ок” скидывает несколько страниц какого-то чтива об ответственностях и обязательствах. Правильно - да. Комфортно - вряд ли. Даже если и прочитает, то в конце все равно будет куча вопросов “зачем” и “почему”, уж поверьте.

Давайте просто поможем человеку.

Расскажи, что такое разработка

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

Да, наша цель - сделать продукт, который удовлетворит нашего заказчика. Но наш заказчик ничего не знает о том, как это работает изнутри. Конечно, чтобы видеть красивые пиксели в браузере ему не нужно знать, что под капотом. Но таким образом, вы сразу отрежете пачку вопросов “а почему?”.

“А почему ты не можешь мне подвинуть этот блок чуть правее в 10 вечера?”

“А почему у нас на сайте баг?”

Все это можно проговорить в процессе повседневного общения. Это не займет много времени, но даст заказчику немного понимания происходящего.

Определите фронт работ и вознаграждение

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

Оцените стоимость проекта. Также не забудьте оценить стоимость правок.

Попроси помощи со сбором требований

Найди человека, который поможет тебе собирать требования от заказчика. Если ты уже какое-то время в IT, то у тебя наверняка есть знакомые владельцы продуктов, менеджеры или лиды. Как ни назови, но такой человек тебе сильно поможет.

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

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

Фиксируйте прогресс

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

Старайтесь работать по принципу:

1. Собрали требование

2. Создали задачу

3. Сделали

4. Собрали фидбек

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

Двигайтесь небольшими релизами

Договоритесь разрабатывать сайт релизами. Например, раз в 2 недели.

Этот пункт вытекает из предыдущего. Двигаясь небольшими шагами вам будет проще отслеживать прогресс и фиксировать его.

Определите сроки поддержки продукта

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

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

Заключение

Буду рад критике. Спасибо.