Комментарии 48
И каждый такой финт ты должен фиксировать на доске
Каким софтом для этого пользуетесь, если не секрет?
Несвсем понятен параметр "важность" в вашей формуле. Можете раскрыть подробнее?
Отличные советы без лишней воды. Спасибо, добавил в закладки.
Вещи очевидные, но их надо выстрадать. Ни в коем случае не надо "входить в положение" и "вот тут чуть поправлять". Все фиксируется, все оплачивается. И да, не работайте с мудаками, заказчиков хватает.
EDIT только тут и обратная сторона: пишешь, что работаешь над проектом с_ по_ и доступен в это время для обсуждения - работай и будь)
Есть ещё один вариант:
- бро, давай ко мне на фуллтайм
- да не бро, у меня тут свои проекты, леваки
- да не вопрос
- ок, давай )
Подскажите где вы ищите проекты на стороне?
Интересно было бы ещё узнать как вы договаривались о совершении оплаты (какие-то платформы где нужно внести депозит, просто 100% предоплаты или ещё что-то)
Чтобы не получилось так что половина работы сделана или все сделано а заказчик говорит "а мне уже не нужно"
Что насчёт ТЗ - кто пишет, оплачивается ли время на ТЗ как этап проекта? Ценит ли заказчик этот этап (написания, тщательного согласования) или рассчитывает "чтобы всё побыстрее"?
Весь труд, который принесет заказчику профит - должен оплачиваться. Что насчет ТЗ?
ТЗ - это документация к системе. Хорошее ТЗ сэкономит много времени, как во время работы над проектом, так и при его поддержке, особенно если поддержкой будет заниматься другой разработчик.
Так что ответ - определенно да. Выносите в отдельный этап, договариваетесь об оплате этого этапа, объясняйте бизнесу всю выгоду от получения ТЗ.
ТЗ описываете словами, или с помощью каких-либо нотаций:
BPML, UML и других ?
А можно ли в одном ТЗ комбинированно - часть на BPML, а часть на UML ?
Как раз пишу статью на эту тему, если коротко - пишу словами, так, чтобы понял и ребенок. В основном мое ТЗ состоит из юзкейсов, которые я вытягиваю из заказчика.
По поводу нотаций - тут как совесть подскажет, потому что ТЗ может потом уйти другому разработчику. Если такой сценарий исключен - то хоть на иврите, как вам удобно)
Хех, как всё знакомо)
Несколько лет уже до обеда на основной работе, после - свои проекты или заказы напрямую.
И до сих пор не научился правильно оценивать работу (( вместо этого сразу озвучиваю стоимость часа и ооочень примерную вилку. Какие-то доработки в процессе? Не проблема - вы платите за часы, я хоть год буду кодить)
Правда часть сразу отсеивается, но зато с оставшимся никаких проблем - они покупают моё время. Да и у большинства вообще тз нет. Им удобнее
По большей части согласен, разве что вот с этим абзацем не могу согласиться:
Веди репозиторий так, будто ты работаешь в команде. Помечай коммиты префиксами, старайся чаще коммитить, разделяй ветки на задачи. Всегда готовься быстро вносить / откатывать изменения. Это сэкономит тебе несколько десятков часов в будущем.
Написание кучи отчетов самому себе и полномасштабное ведение репозитория гарантированно потратит десятки часов сейчас, чтобы возможно сэкономить час-два в будущем (скорее всего нет). Обычно более чем достаточно просто время от времени сохранять промежуточные версии с датами.
Вспоминать и восстанавливать что-то, написанное год-два назад - всегда головная боль, даже с самыми подробными коммитами. И даже при работе в команде обычно всё сводится к тому, что "втопку всё, быстрее будет просто переписать эту фичу без оглядки на старый код, там уже слишком много всего поменялось". Но в команде-то репозиторий хоть имеет смысл использовать, но по другим причинам.
Чтобы быстро вносить/откатывать изменения, процесс внесения/отката изменений должен содержать минимальное количество телодвижений.
Например, поменял цифру в конфиге, ctrl+s, залил файл. Потестил.
Всё сломалось? Ctrl-z, ctrl-s, залил файл. Может, комментарий написал рядом, мол "тут не меняй, а то всё ломается". Занимает секунды.
Делать то же самое по всем регламентам через репозиторий - на порядки дольше.
Полностью согласен, отчеты ради отчетов и технологии ради технологий тормозят процессы как в командах, так и в сольных проектах.
Но ведение гита, правильное, не занимает много времени! Это полуавтоматическая процедура, коммит, мр.
Хот фиксы в обход регламентов похожи на снежный ком. В какой-то момент весь проект становится одним большим костылем, где под новую фичу проще написать с нуля вообще все .
Предлагаю сойтись на том, что важно сохранять разумный баланс)
Местами не могу согласиться. Видимо от компании зависит. У нас "в топку всё, переписываем" - это крайне редкий кейс. Зачастую допилить всё же оказывается выгоднее по времени, хоть и потенциально будет с костылями (если не хватило масштабируемости).
С проектами на оутсорс не сталкивался. Поэтому сложно судить, как там лучше. Но для домашних пет проектов стараюсь какую-никакую документацию поддерживать. Правда обычно это делаю не попутно: делю проект на небольшие спринты и в конце спринта доделываю доку. Конечно там далеко не doxygen со всякими вики. Не редко даже просто в свободной форме бывает с кратким описанием модулей. Если подзабиваю, а потом возвращаюсь, оказывается полезным, особо учитывая моё косноязычие на нейминг. Ну и unit тесты. С ними даже интереснее выходит. Кейсы сначала описываю просто в markdown, который потом использую как чек лист. Этот файл после и заливаю в репу (или бью на комменты к кейсам). Коммент/файл помогает понять, о чём каждый кейс, а остальное (особенности работы частей основного функционала, граничные случаи, подводные камни) уже по коду теста.
Тут в корне не согласен. Дробление на коммиты в удобном IDE занимает насктолько ничтожное время, что этим можно пренебречь. Ветки, может, и не нужы по большей части, но они могут сильно выручить при эксперементах.
Ведение тасков - это не бюрократия, а планирование, которое в любом случае приходится делать явно или неявно. С ведением тасков, кстати, есть еще один побочнгый эффект - если кленту предоставить доступ к доске, это повышает доверие. Фрилансер уже не выглядит рядовым халтурщиком. И отпадают вопросы типа "Как успехи".
Такие вещи съедают много времени только при использовании новых инструментов, в привычной среде это максимум несколько процентов от рабочего времени. Но для проектов меньше 50 часов (учитывая потенциальные доработки) этим действительно можно пренебречь.
Мне 17. Я учусь в школе, готовлюсь к экзаменам, но в то же время чутка подрабатываю на фрилансе с использованием Python. Очень сложно совмещать и обучение, и фриланс, которым я занимаюсь чисто для себя. Но ваши советы - золото. При следующем заказе обязательно буду использовать. Спасибо за пост!
Вам спасибо!
Удачи в карьере!
для начала, научись работать хорошо хотя бы на одной работе. А потом уже задумывайся о таких манипуляциях. Более того, работая там и там, ты обрекаешь себя на сами по себе проекты сомнительного качества, а значит - сильно ограниченную возможность развиваться. Короче, сначала выжми все из одной работы, дорасти до топ рейта, поучаствуй в реально сложных проектах, доведи проект от создания воркспейса до маркета с поддержкой - а потом можно и о лайфхаках подумать. Годам к 30-ти
классика же. Матрица Эйзенхауэра
по классике координат две: срочно/не срочно, важно/не важно
тут добавлена ещё одна, понятно/не понятно
а в остальном ничего нового
Все по делу, много лет назад пришел к похожим выводам. Но главный вывод - повышать рейт на основной работе выходит выгоднее чем тянуть несколько проектов.
Такое ощущение, что весь мир IT ограничен поделкой сайтов под копирку с небольшими вариациями на удаленке.
То чувство, когда ты на основной работе получаешь в 2 раза меньше....
Гребанные айтишники получают 2к в час а ты 2к в день
Привет! А почему неважные задачи по формуле трудозатрат оцениваются больше чем важные? И чему равняется t(баз)? Есть отдельная табличка с t(баз) для типовых задач в Вашей сфере?
Статья очень хорошая, спасибо
Привет!
Нет, такой таблицы нет, но идея отличная. Базовое время - t(баз) - примерный срок, в который я оцениваю задачу. Точная оценка задач - супер скилл, который можно всю жизнь развивать, так что такие методики (вышеупомянутая матрица, 1/2 длины окружности с радиусом t(баз)) призваны максимально уменьшить риск срыва срока.
Неважные задачи (те, которые заказчик не ждет так сильно) зачастую выпадают из контекста. Проект растет, увеличивается время внедрения нового функционала.
Навряд ли вы забудете или затянете реализацию функции, которую заказчик каждый день просит к столу)
Всегда был вопрос: как оценивать свою работу в доп.проектах. Ваша формула очень понравилась, рассчитана на разные ситуации и задачи, попробую теперь поработать по ней)
Как совмещать основную работу и проекты на стороне