kn0ckn0ck

"Казалось бы все хорошо, но я хочу развивать эти навыки" - это о зрелости процессов. Нет смысла бесконечно развивать процессы, смысл есть в организации зрелого процесса (относительно компании, команды, задачи).

Самая распространенная модель зрелости в IT = CMMI (CMMIDev). Очевидно, вам туда.

Знакомьтесь с задачей в два этапа:
1. Цель первого этапа: go / no go, то есть понять вам: тянете, хотите, интересно, есть ли профит и т.п. Это знакомство с задачей за ваш счет. Очевидно, что знакомиться долго не выгодно, однако, если получите контракт, то это время окупится.
2. Цель второго этапа - оценить стоимость. Этот этап нужно продать заказчику. Нет никакого смысла составлять ТЗ за свой счет, тем более, что это отдельная и самодостаточная услуга. Заказчик платит за ТЗ, вы существенно снижаете риски недооценки. Если заказчику ТЗ понравится, то контракт ваш на 90%.

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

То есть схема простая и давно отработанная: интерес (2 часа) -> ТЗ (3 дня, $) -> код (3 месяца, $)

Дно, ха-ха :) Я так полагаю, что 80% аудитории в этом случае такое же "дно".
Если человеку нравится кодить, то нужно идти туда, где требуется кодер на C/C++. Это вполне нормально и полно в банках, у разработчиков мед. софта, у разработчиков встраиваемого ПО/оборудования, у военных (во, может ему в науч. роту?)
Вот когда накодится поуши, тогда можно что-то дальше думать. А может там и останется и это нормально для развития профессионала, напишет потом что-нибудь в духе Александреску :)

Это не один продукт, это целый класс систем под названием Application Lifecycle Management (ALM). Суть в том, что на общей платформе (или общей базе данных) или тесно интегрированных отдельных инструментах, организуется процесс разработки от стадии сбора первичных требований до стадии эксплуатации и поддержки готового решения.

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

Основной причиной тут мне видится изолированность этапов производства ПО. Обычно отдельно от всего формируется ТЗ, отдельно и кем-то там создается UI/UX, потом отдельно еще кем-то эти все фантазии имплементируются и еще потом кем-то там это все поддерживается.

Единый центр интересен только с точки зрения управления (одному или паре участников всего этого процесса). До сих пор ни одна крупная компания-разработчик ПО не предложила решение, которое удовлетворило бы всему разнообразию, царящему в веб-разработке. А раз так, то путь один - интеграция отдельных инструментов в общее решение, так и делают в основном все.

Кстати, есть и позитивный пример, это Siemens PLM. Один производитель мега-ПО, используемого в промышленном производстве (самолеты, машины, ЖДТ и т.п.). В этом сегменте все по-другому, потому что там все сильно зарегулировано и конечный исполнитель скорее работает по системе, а не настраивает/выбирает что-то под себя.

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

Определите наиболее весомые для проекта риски. Из того что перечислено, на мой вкус, это все яйца в одной корзине (один разработчик) и отсутствие тестирования. Важно понимать, что наличие костылей само по себе не так уж и критично, как поют некоторые спецы. Куда критичнее отсутствие регрессионного тестирования.

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

С задачей по настройке CI я бы тоже не спешил. Если время выполнения одной задачи занимает неделю, то ускорение выпуска сборки через CI на 1 день ничего не решает. CI хорош, когда несколько разработчиков делают изменения в своих ветках, когда есть автотесты и т.п.

Отсюда вытекает первоочередная задача - разработка автотестов, которые будут выполнять важнейшие функции:
1. фиксировать текущие требования к системе, то есть отвечать на вопрос как оно должно работать
2. страховать от ошибок, которые могут возникать из-за костылей и неопытных программистов
3. стабилизировать ветки разработчиков перед слиянием в мастер-бранч

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

Битрикс24

Вообще-то, работать нужно стоя, как это делают в Facebook и Google

Со стороны работодателя здесь только одни плюсы, поскольку нет необходимости платить за работника различные взносы (пенсия, налоги). Более того, это нетрудовые отношения, таким образом трудовой кодекс соблюдать не требуется.

Со стороны работника, который хочет честно работать, не будет часто болеть, готов пожертвовать отпуском ради доп. заработка, готов к ненормированному раб. дню, здесь тоже положительный момент, поскольку выплаты в различные гос. структуры он кладет себе в карман.

Посчитаем (по РФ):
- налоги на работника 40% (13% НДФЛ + 26% ПФР/ФНС + ~1% ФОМС).
- налоги с ИП ~8%, это 6% с дохода + страховые взносы (от 25 000 руб. в год), зависят от дохода, но не очень большие + ведение примитивной бухгалтерии в online-сервисе (9 000 руб. в год).

Таким образом, в случае ИП можно положить себе в карман +32% от оклада. Просто не забудь об этом напомнить работодателю :) Сделка должна быть честной.

Бывают задачи, решение которых никак не находится. Думаешь, думаешь, но ничего не придумывается. Такие задачи бывает достаточно оставить на несколько часов/дней (переключиться) и решение приходит гораздо быстрее. Это нормально.

Другое дело, что частое переключение между задачами - плохо влияет на производительность и на качество решения всех задач. Это плохая практика.

Я думаю выходом будет работа в инструменте, который объединяет в себе совместную работу над ТЗ и планирование/контроль задач по исполнению этого ТЗ (макеты, доработки и т.п.).

Заводите под заказчика отдельный проект, в нем есть Wiki, в ней можно писать требования или можно импортировать из MSWord, в чем там заказчик ТЗ изначально записывает. Там же можно обсуждать разделы ТЗ, добавлять макеты, их обсуждать и т.п. Заказчика запускаете в проект.

По каждому разделу ТЗ создаете задачи на подготовку макетов, доработку ТЗ, реализацию (разработку). Там же видите их статус (выполнено/не выполнено).

Все это можно организовать при помощи связки онлайн-редакторов (google docs, dropbox paper) и таск-менеджеров. Но, имхо лучше в одном сервисе это иметь, например, как сделано в scrumboard. В базе знаний пишем требования, на основе статей базы знаний создаем доработки или задачи - что еще нужно?