Тим

Как правильно релизиться в больших компаниях?

То что ты описал указывает на слабое планирование. Должен быть менеджер проекта который организует процесс планирования в котором будет участвовать Продакт Овнер, Тимлиды всех групп и он сам. Результатом планирования должна получится диаграмма ганта или Roadmap в котором будут учитываться взаимосвязи и будут заложены адекватные риски. Я это делаю всегда, и у меня на проектах почти никогда не бывает таких вот блокеров как ты описываешь.

По поводу релизиться есть разные методики.
Версионность это хорошо если вы работаете через API, а если у вас несколько команд бекенда которые пилят один и тот же монолит то нужно внедрять практику GitFlow и ставить техлида который будет заниматься мержами веток в релизы и правильно построит адекватный GitFlow.

Версионность апи это отличная практика, ей нужно учиться и не слушать тех кто говорит что это сложно. Это не сложно. А версионность позволит релизить бекенд не дожидаясь фронтенд и не ломая его на продакшене.

Что бы релизы проходили плавно нужно погрузить себя в книжки по Continues Delivery и занятся докеризацией своих сервисов или монолита.

print(r.text.encode("utf-8")) ?

Знаком с десятком собственников которые держат аутсорс-аутстаф компании (Украина, Беларусь). При штате 30-100 человек, чистая прибыль составляет от 5 до 20% прибыли. Больше всего прибыть при меньшем количестве сотрудников, так как чем больше сотрудников тем больше расходы на офисы, отпуска и поддержание софта и сервиса в адекватном виде. Доходы у среднего аутсорсера в 30-50 человек в мобилке и вебе около 1-2 миллионов в год при рейте 25-30$ / ч. Средняя загрузка по программистам 60-80%, то есть 40-20% всегда в простое и ожидают новых проектов/никуда всунуть.

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

Предпочитаю не приступать к исполнению проекта пока не согласованы критерии приемки и форма поставки. Иногда оценка проекта и деньги меняются радикально когда услышишь критерии приемки и форму поставки. Одни сейлзы подписали контракт где заказчик прописал "Не более 2х минорных багов в продакшене" и компания встряла на треть стоимости проекта в попытке исправить всё.

В связи с обилем .net проектов - Team Foundation Server. Туда Requirement, по ним менеджерские Task, к ним Test Case, и Change Set. Разработчики в праве бить на сабтаски в любом кол-ве. Занимается этим тимлид. Если ПМу утвердили требования и поставили как таск, то запланировал, передал в работу тимлиду, дальше тот уже отвечает за исполнение. По сути конвеер.

Изучайте техники оценки. Их в интернете много.
Другое дело, что прибавлять в сухую процент к оценке это бандитские методы. Так можно работать только с "колхозниками" которые в IT и в разработке не смыслят.

При составлении ТЗ руководствуюсь логикой - Описывай то, что непонятно или нестандартно. Можно оценить проект по рискам, выделить какие элементы проекта имеют самые высокие риски и начинать описывать их. Содержание никогда не планирую, оно появляется автоматически через удобную фичу Ворда - "автосодержание".

В конце написания, форматирую, перемещаю текст по доке для красоты. Когда пишу тз, то пишу просто по порядку без структуры. Потом отдаю на тестирование разработчику и тестировщику. Они комментируют ТЗ задавая вопросы что где не понятно, или предлагают свой вариант описания если я написал недоступно\неправильно. Потом комбинирую правки и отдаю руководству. Руководство добавляет свои 5 копеек и можно показывать клиенту. (постоянный показ клиенту проходит по мере написания ТЗ, что бы не оказалось, что вы писали 2 недели чепуху которая клиенту не нужна).

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

Когда при проектировании у человека уходит час на форму авторизации и он думает и ищет примеры как расположить Remember me, и подписать ли её Remember, или Remember me или Remember login и т.д., то это уже проблема.

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

Для вдохновления листаю bootsnipp.com и https://dribbble.com/

1. Сбор требований
1.1 Написание функционального задания
2. Проектирование
2.1 Интерфейса
2.2 Архитектуры
3. Планирование
3.1 Декомпозиция проекта на задачи
3.2 Определение необходимых ресурсов
3.3 Составление графика реализации
4. Согласование
5. Документирование
5.1 Написание технического задания
6. Старт разработки
6.1 Разграничение ролей и обязанностей
6.2 Разработка по плану
6.3 Показ демоверсии 1
6.4 Корректирование плана и требований после демоверсии 1
6.5 Разработка по плану 2
6.6 Показ демоверсии 2
6.7 Утверждение версии, заказ дизайна или выход на еще одну демоверсию и возврат к пункту 6.7
6.8 Тестирование версии, стабилизация и релиз бета версии
6.9 Верстка дизайна и внедрение верстки в проект
7. Финализация оставшегося функционала
8. Нагрузочное тестирование, тестирование безопасности
9. Рефакторинг
10. Пред релизная демонстрация и утверждение на деплой
11. Документирование кода и проекта
11.1 Комментирование кода
11.2 Составление хелпа по развертке проекта, настройке конфигов, включении\отключении фич не выведенных в CMS
12. Деплой
12.1 Установка на релиз сервер
12.2 Нагрузочное тестирование
12.3 Настройка бекапов и контроля версий для апдейтов
13. Сапорт

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

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

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

Современная CRM должна показывать эффективность работы отдела продаж. Что бы увидеть эффективность, нужно её собрать. В нашей CRM мы считаем эффективность отталкиваясь от действий (звонок, письмо, встреча), и высчитывая процент успешности после совершения того или иного действия. Если совершив звонок по контакту компании, статус лида сменился с холодный на отказ, то это уходит в минус рейтинг. Если с холодного на горячий то в плюс рейтинг. И т.д.
Соотв за месяц можно смотреть сколько всего продажник совершил звонков, писем, назначил встреч и какой процент успешности по переходу с холодного на горячий.

Но если честно, успехи иллюзорные.

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

Часто перечитываю и осознаю насколько она глубокая. Главное осознать аналогии.