Как запрогать сайт другу и не поссориться
Эта статья прекрасно подойдет тем, кто только собирается запрогать что-либо другу или уже начал работу над проектом. В ней я опишу, какие вещи лучше проговорить заранее, чтобы вы успешно завершили проект.
Немного о себе
Я фронтенд-разработчик, ментор и делаю сайты на Angular за деньги вот уже 5 лет. Работал на фрилансе, в крупных компаниях и в стартапах. Помимо основной работы я завершил 8 сторонних проектов. Те ошибки, что я допустил, стали основной для этой статьи.
Я не юрист и не профессионал договариваться с людьми. Я учился общению с людьми, менторил, занимался со специалистами, но я всего лишь разработчик. Я люблю писать код и получать за это деньги.
Договор
В идеале — да, но это не предмет этой статьи. Договор — беспроигрышный вариант, когда вы делаете что-то за деньги. Но мы же все таки хотим просто помочь кому-то, не так ли? Представьте, что вы попросили хорошего друга помочь с каким-то непростым делом, а он вам вместо «ок» скидывает несколько страниц какого-то чтива об ответственностях и обязательствах. Правильно — да. Комфортно ли — вряд ли. Даже если и прочитает, то в конце все равно будет куча вопросов «зачем» и «почему», уж поверьте.
Давайте просто поможем человеку.
Расскажи, что такое разработка
Расскажи ему о том, как выглядит твоя работа, пока идете с ним в кофейню. Расскажи, например, что тебе нужно сделать, чтобы он увидел новую фичу. Или как выглядит процесс поиска и устранения багов.
Да, наша цель — сделать продукт, который удовлетворит нашего заказчика. Но наш заказчик ничего не знает о том, как это работает изнутри. Конечно, чтобы видеть красивые пиксели в браузере ему не нужно знать, что под капотом. Но таким образом, вы сразу отрежете пачку вопросов «а почему?».
«А почему ты не можешь мне подвинуть этот блок чуть правее в 10 вечера?»
«А почему у нас сайте баг?»
Все это можно проговорить в процессе повседневного общения. Это не займет много времени, но даст заказчику немного понимания происходящего.
Определите фронт работ и вознаграждение
Обсудите, что конкретно хочет заказчик. Зафиксируйте это. Как это должно выглядеть, в какие сроки он это хочет и когда работа считается выполненной. Составьте схему сайта, примерный вид и задайте вопросы.
На основе оцените стоимость проекта. Также не забудьте оценить стоимость правок.
Попроси помощи со сбором требований
Найди человека, который поможет тебе собирать требования от заказчика. Если ты уже какое-то время в IT, то у тебя наверняка есть знакомые владельцы продуктов, менеджеры или лиды. Как ни назови, но такой человек тебе сильно поможет.
Дело в том, что после первого месяца разработки ты поймешь, что собираться требования, их прогать и собирать фидбек — процесс крайне непростой и изматывающий. Не стоит недооценивать эту часть.
Поэтому такой человек сэкономит тебе много времени и сил. Их можно потратить на разработку.
Фиксируйте прогресс
Создайте трекер задач и каждое требование вносите туда. Создайте чат и старайтесь обсуждать всё, что связано с проектом, только там. Относитесь к пожеланиям заказчика ответственно и уважительно.
Старайтесь работать по принципу:
Собрали требование
Создали задачу
Сделали
Собрали фидбек
И так по кругу. Таким образом ваша работа становится более прозрачная для вас и для него. Ваша работа всегда должна быть зафиксирована.
Двигайтесь небольшими релизами
Договоритесь разрабатывать сайт релизами. Например, раз в 2 недели.
Этот пункт вытекает из предыдущего. Двигаясь небольшими шагами вам будет проще отслеживать прогресс и фиксировать его.
Определите сроки поддержки продукта
После релиза нельзя бесконечно поддерживать продукт. Вам никто не может запретить этого делать. Но я думаю, вам не хочется спустя пару лет после релиза, когда вы уже забыли про этот проект и пилите другой, получить сообщение, мол там баг такой-то такой-то в админке если сделать так-то так-то.
Подумайте, сколько после релиза вы готовы поддерживать продукт бесплатно. После этого времени — фиксы платные. Так вы не попадаете в ловушку, когда заказчик думает, что его интернет-магазин вы будете фиксить бесплатно до конца жизни, потому что вы когда-то написали этот код.
Заключение
Буду рад критике. Спасибо.
