Saboteur

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

Экстасенсов не существует. Диагнозов понаставляют...
Или подобрать нюни или к врачу.

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

2. Сделайте два сайта - один для разработки, другой боевой. И научитесь переносить с сайта для разработки на боевой изменения. Программистам давайте доступ к сайту для разработки

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

А в вашей команде есть тестировщики?
А в вашей команде code review есть?

Баги - это нормальная ситуация, и их надо просто исправлять а не бояться выявить.

Я джуниор. Мне приходилось работать в команде (одной и той же) над разными проектами. Один из проектов обнищал, не смог больше кормить команду. И там теперь всего один разработчик. Всего один разработчик в проекте с непростой архитектурой, с C++, JavaScript, Node.js и Lua. И он джуниор. И он - я.

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

Все проекты, с которыми мы работали, это форки, или мы вообще подрядчики. То есть код не наш. Соответственно главная (по мне) проблема это изучить код. И от сеньора и лида здесь пользы не бывает. Потому что отвечают они на твои вопросы по коду не быстро, не всегда, и вообще не обязаны отвечать.
А изучать код сам я вполне могу и без сеньора и лида.

Так вы один или у вас есть сеньоры и лиды?
У лида должна быть команда, у него не может быть всего лишь один джун. Возможно все-таки вас несколько и у вас не проект, а конкретный один компонент?

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

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

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

Если все происходит именно так, меняйте работу.

Без сеньора и лида я рискую сорвать лишь более-менее глобальный дедлайн. И тогда меня пошлет заказчик и придется умолять заказчика вернуться. Всего 1 раз! А сеньор и лид за это время раз 5 успели бы меня отругать.

Сеньор и лид это локальные ребята. Заказчик если пошлет, он просто наймет другую команду и никакие мольбы уже не вернуться. А деньги идут именно от заказчика, а не от сеньора, лида или джуна. Поэтому если заказчик удовлетворен - это самое-самое главное. На все остальное (качество кода, работоспособность продукта, наличие джунов/лидов/сеньоров) - плевать. Главное убедить заказчика что все хорошо, и чтобы он продолжал давать денег.

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

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

Без сеньора и лида я так же делаю упор на сдачу в срок и на безбажность. На качество иногда подзабиваю. Зато всегда спокоен и уверен, что если что-то сдаю, то это навсегда. И соответствующим образом проверяю код на баги. Делаю саморевью, а от него куда больше пользы, чем от ревью сеньора и лида, которое ищет где поэстетствовать, а не где баг. Число багов после ухода команды резко упало.

Если навсегда, то почему в принципе вы еще пишете код? Разве он не должен был быть уже давным давно написан навсегда?
Баги могут быть технические и логические. Если вы хорошо знаете бизнес заказчика - это одно.
Число багов после ухода команды может упасть потому что разработка упала. Гораздо меньше багов, если никто ничего не пишет, это же Л - Логика.

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

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

Сорри за много букв и у меня вопрос, это везде так или от сеньора и лида бывает и польза?

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

Для начала с терминологией.
Overtime - это работа на работе во внеурочное время, СОГЛАСОВАННОЕ и одобренное с заказчиком. Обычно оно оплачивается или компенсируется.
А то, что вы просто задерживаетесь на работе по личным причинам - это просто ваше личное желание.
Если у вас какая-то проблема, никто не мешает пойти домой, сесть за комп, и разобраться с технологией, проблемой.

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

Поэтому:
Нет никаких проблем, если вы задерживаетесь на работе, разбираясь с технологиями. Просто постарайтесь чтобы это не превратилось в образ жизни. Если год задерживаетесь на работе и конца-края не видно, остановитесь.

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

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

Есть определенные требования к альфа, бета и полному релизу.
Если требования к альфа выполнены, и альфа запланировано, то ее нужно выводить.

А потом, наверно, надо будет выпустить еще одну версию, устранив и перекроив часть проблем. А потом еще. Какой-то подход "лишь бы не сидеть сложа руки".

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

Потому что хорошая продумка в течение нескольких человеко-суток позволит наперед продумать и обсудить все моменты. То, что никто это не умеет, это просто человеческая тупость. Надо больше развивать такое качество, как перфекционизм - оно принципиально не позволит что-то переделывать, потому что от переделок остаются следы, а это уже не идеал. Разве это не сэкономит больше ресурсов, чем потратит?

Если ты такой умный, почему ты работаешь в этом проекте, а не являешься его владельцем или хотя бы тимлидом команды, которая будет слушать именно тебя, как все надо сделать?
Или может быть твой "перфекционизм" заключается в понимании небольшой части работы, которую выполняешь именно ты, а обо всем остальном, что еще происходит в проекте, у тебя очень мало понимания?

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

Мой главный герой - фронтенд-разработчик, а компания, в которой он работает (крупная и ведущая в стране) - занимается аутсорсингом и консалтингом в сфере IT.

По идее, герой работает в команде, где есть ещё один фронтенд, один бэкенд, двое тестировщиков, серверщик (сисадмин), иногда к ним подключаются iOS и Android разработчики и аналитик. У команды есть руководитель (или тимлид, или менеджер - как правильней?)

Крупная компания - это 1000 человек минимум. А лучше 3-5к людей.
Проект, в котором всего 2-3 разработчика это просто ни о чем. В аутсорсинге такие мелкие проекты - это нонсенс, нет смысла искать заказчика и заключать с ним договор, выделяя всего 3-5 человек. Разве что это мелкие под-проекты внутри одного большого заказчика.
И если герой - единственный главный разработчик то он и будет тимлид, потому что тимлид - ведущий разработчик, иногда совмещающий системного архитектора.

1. Правильно ли подобран состав команды для крупной компании? Может, стоит кого-то исключить/добавить?

Либо сделать ГГ тимлидом, либо добавить еще человек 10-15 минимум в проект.

2. Какого рода проекты обычно поручают команде? Сайты, ПО, приложения? Поскольку главный герой - фронтенд, и сама команда талантами не блистает, нужно что-то не слишком обременительное.

Вести какой-нить небольшой проект внутри крупного заказчика, например систему для ВНУТРЕННЕЙ отчетности, которой заказчик пользуется для своих нужд, а не для работы со своими клиентами.

3. Роль руководителя (тимлида). Как он обьясняет своей команде то, что хочет заказчик? Как часто он появляется в офисе и контролирует ли процесс работы? Как общается с подчиненными - в роли злого начальника или на равных?

Тим лид является ведущим разработчиком. Собственно работает на архитектуру проекта, согласование взаимодействия с другими сервисами на техническом уровне. Не путайте тимлида и менеджера проекта.

4. Дедлайны разных проектов (например, сколько по времени делается один сайт и во сколько этапов?)

Если вы кроме сайтов не знаете о софте, то не пишите о крупном аутсорсе. Напишите о маленькой но гордой "рога и копыта". Проект может длиться годы, десятки лет. Не так уж много крупных компаний, которые существуют всего несколько месяцев.

5. Может ли заказчик советовать вносить правки, если его не устраивает результат? Перед работой вообще заключаются какие-то договора и кто за это ответственен?

Конечно. От менеджера проекта зависит насколько он убедит заказчика заплатить за дополнительные правки и советы. От менеджера проекта зависит как он заключил договор и как он договроился о приеме удовлетворительного результата.

6. Процесс работы фронтенд-разработчика. С чего он начинает свою работу первым делом? В чем состоит самая сложная часть его работы и как он взаимодействует с другими членами команд? Есть ли там какие-то моменты, когда фронтенд и бэкенд должны что-либо сделать вместе? И есть ли другие случаи, когда фронтенд должен технически взаимодействовать с другими профессионалами?

Есть системный архитектор, есть UML и другие слова. Может вам действительно найти дружелюбного разработчика из крупной компании, который будет регулярно консултировать? Потому что иначе получится не рассказ о разработчике, а рассказ о выдуманном мире с выдуманными технологиями и процессами.

7. Сисадмин. Он в одном офисе со всеми работает или в другом месте где-то? Как выглядит его рабочее место? Нужен ещё процесс его работы. Если можно, опишите простыми словами.

В аутсорсе есть отдельно сисадмин, отдельно девопс. Работают похоже, процесс работы люди изучают годами. Большинство джунов не знают о процессе работы, а вы хотите просто парой вопросов его выяснить.

8. Тестировщики. Они, вроде, тестируют почти в самом конце, когда все готово. Но, наверное, и в начале проекта они что-то делают?

Тестировщики бывают разные. Бывает даже tdd, когда сперва пишут тесты, потом приложение. Тестировать можно сразу, потом, или писать автотесты и постоянно их обновлять.

9. Разработчики для ios и android. Если требуется сделать мобильное приложение, то как эти разработчики взаимодействуют с остальными членами команды?

Также как и все.

10. Аналитик. Он точно нужен, или его роль может играть и тимлид?

Чтобы написать сайтик - не нужен. Чтобы написать бизнес-приложение нужен.

11. Состав команды, в целом, может меняться, в зависимости от проекта? Куда в таком случае отправляют «ненужных» работников? В другую команду?

12. Миттапы, совещания, летучки. Как часто проходят, кто участвует и что там обсуждают?

Зависит от того, какой agile настроен. Вдобавок они могут быть между конкретными командами или даже между конкретными людьми.

13. Рабочая атмосфера. Как общаются между собой программисты в перерыв? У них есть какие-то особые темы для обсуждений или они могут как и обычные люди, разговаривать о всяком постороннем? Есть «свои фишки» в общении?

У них есть какие-то особые темы для обсуждений или они могут как и обычные люди

они могут как и обычные люди

Нет, мы Марсиане.

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

Могут быть специальные служебные помещения. Например туалет, кухня, ресепшн. Может быть и серверная.

15. Есть какие-то особо важные нюансы, которые непременно стоит ещё упомянуть при описании работы?

Да. Не пишите книгу про ИТ, если не работали в ИТ сами. Либо найдите знакомого айтишника, который работает, и напишите книгу про его работу.

Простите, но ваши вопросы вызывают такой диссонанс, что это капец.

Встречается место в котором вы заходите в тупик

Не брать заказы, которые вам не по силам.

В остальном, сложность задач просто занимает определенное количество времени+бюрократия.

technical director

: «Buddy, у тебя нет тех. бэка, поэтому дай другому челу руль и он тебя приведёт к успеху». Стоит ли рассказывать, что это, мягко говоря, «очень плохой ответ».

Смотрите, "Евгений".
Для стартапа у вас должен быть бизнес-план. А именно - кому продавать продукт, кто его уже готов купить и за какие деньги. А у вас на повестке дня просто "как написать продукт".

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

Вы придумали концепт продукта. У вас уже есть примерное ТЗ. То есть задача осталась простая - просто написать продукт.

Если вы не разбираетесь в людях и не можете нанять даже технического архитектора, которому готовы доверитсья, что он уложится в указанный бюджет и напишет продукт по ТЗ - ну идете в контору, заключаете договор, они вам пишут
Если ТЗ нет, то перед выделением 50.000 нанимаете консультанта, который помогает вам написать ТЗ и оценить (можно сразу в контору, которая еще и возьмется потом это писать).
Но будет ли этот проект приносить прибыль? Сможете ли вы его продать - вот в чем главный вопрос. Потому как хороших программистов, которые могут довольно быстро накопить 50к - много, а стартапов подобного плана - мало. Именно потому что кому оно нужно - это вопрос из области продаж и знания рынка.

Пример: у меня есть плейбук ansible который разворачивает гитрепозитарий на групе серверов, но я примерно понимаю, что скорее всего, у "больших дядек" это делается не через плейбук, а через jenkins + docker + webhook, но на практике взглянуть на такое я не могу :)

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

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

Старайтесь не оптимизировать что-либо, а решать конкретные проблемы, типа "вот тут я трачу еженедельно xx часов на рутину. Имеет ли смысл потратить неделю на оптимизацию и сэкономить потом на этом, или рутина связана с процессами, неподдающимися автоматизации (например из-за бюрократии).

CI/CD это не организация команд, это организация процесса автоматической сборки/деплоймента/тестирования.

Для этого девопс/админ или шарящий в этой теме разработчик придумывают правила (branching name conventions, versioning, настраивает соответствующие инструменты и инфраструктуру (teamcity/jenkins/какой-нить bitbucket с пулл реквестами. Чтобы по коммиту собирался билд, проходили юнит тесты, результат деплоился в тестовый энвайрнмент, запускались автотесты, результат возвращался в пулл реквест и подтверждал действие.
Чтобы деплоймент на тестовый энвайрнмент делался одной кнопкой, чтобы деплой на прод делался одной кнопкой с предварительным подтверждением и аппрувалом также в цифровом виде.
Вот это все.

А команды - как угодно можно сделать.

1. ЛЮБОЙ багтрекер будет хорошим решением.
2. Любая локальная вики с поддержкой версионности будет достаточным решением.
3. git со структурой документов/текстовых файлов, да хоть рисунков.

P.S. "не заточенные жёстко на программировании (типа GIT и всё такое)"
Судя по этому упоминанию, вы понятия не имеете что такое GIT и программирование. Потому что GIT можно использовать как угодно. Я бы серьезно посоветовал Вам поиск решения на этот вопрос переложить на более компетентных людей.

Правильные версии - более универсальный вариант. Вдобавок те же фича-тимы могут работать и с версиями.
Чтобы упростить работу с версиями, используйте https://semver.org/lang/ru/

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