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