У многих из нас остается достаточно свободного времени в сутках. А почему бы не монетизировать это время, думает начинающий IT левак? Если работать по три часа в день в будние, брать по 2 тысячи за час, то получится 120 тысяч дополнительного дохода в месяц. Звучит отлично!
Меня зовут Даниил, и я через выгорание, увольнение, споры с заказчиками и успешные проекты научился совмещать карьеру в компании и ведение проектов на стороне.
Entry point
Мы вместе пройдем путь проекта, от согласования до удаления чата в мессенджере, чтобы проследить самые сложные и опасные места, где заказчик жаждет оставить тебя без штанов.
Согласование проекта
Самый важный этап. Именно тут определяется, кто на ком заработает.
Цель заказчика - получить результат за короткое время и меньшие деньги. Конечно, бывают единороги, готовые платить тебе баснословные компенсации, но это редкость. Чаще бюджет приземлен, а сроки сжаты.
Твоя задача - заработать дополнительные деньги, не навредив основной работе. Перечитай прошлое предложение еще раз. Primum non nocere.
Согласование - поиск компромиса между этими целями. Это переговоры, в которых у вас равные позиции. У заказчика есть проект и средства, у тебя возможности и знания. Ты имеешь полное право предлагать удобные для тебя условия и отказываться от неудобных. Самое главное, не забывай:
-
У тебя уже есть работа, она занимает время
-
Заказчик заинтересован в получении результата сильнее тебя
-
Ты не нанимаешься на работу, не берешь деньги в долг, ты продаешь свои услуги
Последний мой проект прошел на таких условиях:
-
Я работаю и доступен для обсуждения в пн-пт с 16 МСК до 20 МСК
-
Час работы в установленное время стоит 2500, вне установленного времени - 3000
-
Правки после сдачи оплачиваются отдельно
Сроки проекта - отдельная тема. Если у заказчика есть дедлайн, например, сделать сайт к открытию магазина, то тут не попишешь. Но зачастую сроки - предмет торгов, и вот как я их считаю (довольно успешно в последнее время):
-
Разбиваю проект на модули (фичи)
-
Оцениваю каждую фичу по трем параметрам: понимание, важность, базовый срок.
-
Прогоняю все фичи через формулу и складываю
n - показатель понимания: 1 - понятно, 1.5 - не совсем понятно, 2 - не понятно.
k - важность: 1 - важно, 1.5 - не очень, 2 - не важно.
70% сверху на отладку (хотя я бы все 100 добавлял).
Получается, для фичи, которую я оценил бы как понятную, важную и реализуюмую за 1 час, общее время составило бы 1 час 42 минуты => 2 часа.
Если бы та же фича была непонятной (требовала ресерча) и неважной (осталась бы на потом), то время получилось бы 6 часов 48 минут => 7 часов.
Да, кто-то скажет, что такой расчет раздувает проект. Но в том то и суть торгов — отталкиваться от максимально выгодной точки. Всяко лучше согласовать раздутый срок, чем сорвать сроки, потому что «блин так сложно оказалось жееееесть».
Работа над проектом
Веди доску, даже если заказчик ее не смотрит!
В идеале - ты сдаешь часть работы, приступаешь к следующей. По факту - доморощенный Маск каждый день придумывает семиколесный велосипед для голубей. Проект обрастает додумками, передумками и приколами. И каждый такой финт ты должен фиксировать на доске, чтобы в случае споров у тебя была возможность продемонстрировать заказчику всю хронологию возникновения задержки / ошибки (если, конечно, это его вбросы вызвали эту ситуацию). Тем более, сложно держать контекст в голове и ничего не упустить.
Сольный проект - всегда соблазн добавить отсебятины, забить на архитектуру, чистоту кода и всю эту навязанную компаниями атрибутику. Но это ошибка. Твоя задача - найти баланс между качеством кода и сроком написания фич. Неминуемо, как утро после ночи, ты будешь расширять, переписывать, дописывать существующий функционал. Так что готовь почву сразу - пиши понятно, оставляй комментарии, будто кто-то другой будет работать с твоим кодом, а не ты.
Веди репозиторий так, будто ты работаешь в команде. Помечай коммиты префиксами, старайся чаще коммитить, разделяй ветки на задачи. Всегда готовься быстро вносить / откатывать изменения. Это сэкономит тебе несколько десятков часов в будущем.
Не давай заказчику менять условия на ходу. Все должно фиксироваться, обсуждаться, пересчитываться. Приведу пример: свой первый проект я оценил в 2 месяца и 250тыс. компенсации. Спустя месяц работы, заказчик, по совету друга, захотел сменить протокол (это было VPN приложение). В итоге проект занял полгода. Я буквально увяз в нем, и это без пересмотра компенсации. Если не хочешь так же - фиксируй договоренности.
Самое важное на последок - работа вперед. Сначала закрывай хвосты на работе. Не допускай переработок, долгов, проблем с менеджерами. Закрывай таски вовремя, чтобы после работы у тебя был чистый разум для проектов.
Перенимай рабочий опыт - наверняка, компания, в которой ты работаешь, имеет немалый опыт в организации работы. Изучай! Используй получаемый опыт во благо!
Сдача проекта
Сдал? До свидания.
Правильнее будет рассмотреть не сдачу самого проекта, а, скорее, сдачу некоторой работы над проектом. Давай рассмотрим ситуацию:
Ты делаешь авторизацию через номер телефона. Имея опыт в этом вопросе, предлагаешь сервис авторизации через звонок, где пользователь должен ввести 4 цифры звонившего номера. Но заказчик настаивает на обычном смс. Вы фиксируете договоренность, ты сдаешь авторизацию, заказчик тестирует ее и принимает работу.
Спустя неделю заказчик приходит к тебе со словами "я на смс-ки потралил 20 тысяч, они ужас дорогие, переделай на звонок".
Как ты поступишь в данной ситуации?
Как следует поступить
Абсолютно не играет роли твое моральное превосходство, так что фразу "я же говорил" можно оставить при себе. Но, совершенно точно, ты должен провести эту правку, как новую работу с отдельной оплатой. Ведь ты уже сдал задачу, заказчик принял, всех все устроило. Это как в ресторане съесть салат, а потом требовать за него деньги, якобы в нем были волосы (хотя тарелка уже пустая).
Позволяя нарушать зафиксированные договоренности ты просто сбиваешь свой же прайс. Раз ты готов вместо часа отработать два за те же деньги - значит готов будешь отработать и три и четыре. Так и вязнут в проектах и бесконечных правках.
Поддержка проекта - трудоемкий процесс, который тоже надо обговаривать. Очень важно отделить его от основной работы, чтобы у проекта был четкий финиш. Нет такой скрижали, где написано, что раз ты сделал этот проект, то и заниматься им дальше тебе. Заказчик заплатил за договоренности, а не за твою душу. Когда все договоренности соблюдены, весь функционал работает, как было обговорено - забирай деньги и отчаливай.
Конечно, если заказчик готов платить за поддержку, а ты располагаешь ресурсом, то это всем на пользу. Но! Все, что было выше, остается актуальным. Фиксируемые договоренности, четкие задачи, никакой благотворительности.
Накопление опыта и портфолио
Каждый проект будет расширять твою компетенцию. С каждой шишкой ты будешь превращаться во все более матерого и матерого разработчика, и спустя какое-то время, тебе будет подвластна еще более трудная задача - управлять другим разработчиком. Тогда твоя маленькая one person company превратиться в небольшую аутсорс студию.
Мягких клавиш, друзья.
Автор: Даниил Азевич
