Как стать автором
Обновить

Комментарии 15

На своём опыте понял, что начинающим разработчикам лучше идти в нормальную компанию. Обосную: искал позицию junior back end, попал в стартап. Сначала всё нравилось — и что можно удалённо работать, лишь раз в неделю приезжая на митинг, и что достаточно неформальное общение. Начал работать — стали всплывать «интересности». Оказалось, что на проекте, который пилится почти год даже не слышали о документации. И, заметив, как я комментирую код (по-джуновски, чтобы самому не запутаться и не забыть ничего) кинули ссылку на неё: «Ну вдруг интересно будет». Оказалось, что из-за малой команды все занимаются всем. И работал я, по сути, на позиции junior full-stack, что накладывало соответствующий отпечаток — было очень трудно разом разобраться в куче технологий, при этом на каждом митинге отмечали как я медленно втягивался, а на вопросы «Ошибка упала, сделал то-то, то-то, всё равно падает, что делать?» отвечали на уровне «Хз, погугли». Описания тасков были жутко недетализированные и невнятные. Часто — с противоречащими формулировками или ссылками на модули, которые ещё даже не начинали разрабатываться. Фидбека практически не было. Как-то раз, осознав, что всё, что я понимал — уже сделал, а остальное написано слишком запутанно — попросил тимлида дополнить описание к таскам. Получил ответ «Ща сделаю». Благополучно прождал несколько часов. Спросил ещё раз — что там с описаниями? Сказал, что сейчас занят и чтобы я написал список вопросов, а он вечером снимет видео по каждому таску. Ок, накатал список, подробно расписал вопросы и детали, которые мне непонятны. Наступил следующий день. Проблема блокерская, я дальше работать не могу. В полдень спрашиваю «Что там с видео?», на что получаю «Сегодня сделаю, у меня же не один проект». Ни сегодня, ни завтра их не было. И тогда я понял, что пойду ка я подальше отсюда. Через неделю нашёл работу и сказал, что ухожу. Стоит ли сказать, что всю эту неделю ни намёка на описание или видео не появилось.
Придя же на новую работу в фирму я в первый же день получил подробный 80-страничный мануал, что мы делаем, как, и зачем.
Из всего опуса, я так и не понял почему вы сами не разобрались? Почему кто-то должен снимать видео (шта??) по таскам?
Да потому что он сегодня разберется сам а завтра придет лид/менеджер/заказчик и скажет что все сделано не_так_как_они_ожидали. Тем более видео он никому не предлагал снимать, лид сам так захотел(это я понял из текста).
Что вообще за каша с разделением ответственности у нас в компаниях? Джун вообще не должен думать о бизнесовой аналитике, он должен думать только о реализации причем так как он джун переодически за*бывать вопросами лида. Лид должен либо отвечать либо скинуть ссылку, либо если вопрос действительно крайне простой отправлять в гугл. Так и строятся отношения в компании.
— Джун решает простые задачи если что спрашивает лида или синьора(и то синьоры не должны брать на себя работу лида)
— Лид управляет тасками внутри команды, общается с аналитиками с другой стороны, немного занимается анализом бизнесовых требований и немного пишет код(очень очень важный)
— Все остальные менеджеры аналитики директора какие то еще левые ребята должны получать доступ к людям в команде только через губку в лице лида.

Все остальное это попытки переложить ответственность со своих плеч на другие и тогда проекты затягиваются, люди с пропавшей мотивацией уходят, а директора считают убытки.
Все верно, особенно список из 3 пунктов, под каждым из которых я готов лично подписаться, но… поделитесь как-нибудь своими соображениями с приверженцами agile/scrum и узнаете много интересного о себе и «правильных» способах ведения проектов… :)
Так стартап — это и есть «неправильный» проект. Это фактически постановка нового эксперимента, здесь не до отчетности. Применение Agille в стартапах это большая ошибка менеджмента.

А тот джуниор ошибался, думая, что надо сделать «правильно», сделать надо было «лишь бы работало».
Имеется в виду, что проблема не в технических знаниях, а в формулировании тасков и их описания (которого к сожалению действительно очень не хватало). Приведу пример, таска номер такой то «Сделать такую то классную штуку». Что вы поймете из такой формулировки? Максимум, что вы сами поняли (додумали). Очень часто такой подход приводил в созданию совсем не нужной «Фишки», либо работающей не так, как хотелось тимлиду.
p.s видео отчеты, видео пояснения были инициативой тимлида
Потому что таски были составлены на уровне «Это будет такая фича, которая реализует возможность добавления постов на стену юзера». Что такое стена, где её искать, как должны посты выглядеть — видимо я это должен был телепатически уловить. Если для этого нужна новая таблица БД, то какие поля? Какие у них типы? Или я должен был делать всё так, как «вижу» (с моим то опытом), а потом надеяться, что прокатит?
… получил подробный 80-страничный мануал, который абсолютно не соответствует действительности, ибо был написан еще в прошлом веке про систему на базе FoxPro для MS-DOS 3.20
80-страничный мануал? Сбежал бы в первый день из такой компании)

Есть же код, он работает — запускай его и смотри. Вот и документация, самая верная и надежная.
Если это «в рамках» фрилансера-одиночки, который работает над одним проектом (и то небольшим) — может быть. Но когда речь о чем-то большем… А вы когда-нибудь работали над большими проектами в команде? :)
Работали и неоднократно. 6 млн строк на PHP, в которых можно было найти коммиты 5-6-летней давности — достаточно большой проект? Так вот ни одна документация не в силах была бы передать бизнес логику некоторых частей этого проекта. А правки вносились постоянно командой из 30+ человек. Боюсь представить потенциальный размер wiki по бизнес-логике такого проекта и уровень «сказочности» описанного в ней.
Почему постоянно забывают упомянуть, что в крупных компаниях тоже есть интересные проекты? К тому-же есть чистые прогеры — этим лучше идти в состоявшиеся компании; а также есть люди с предпринимательским шилом в заднице — этим в стартапы.
Мне кажется все зависит от конкретной компании и конкретного специалиста. Во всех случаях есть множество факторов, влияющих на рабочие процессы, свои плюсы и минусы. Единственное, что нужно (и что, собственно говоря, самое сложное) — это правильно определить эти факторы как можно заранее и принять правильное для себя решение при выборе компании.
Учавствуя в стартапе выражу мнение, основанное на ощущениях, т.к. сравнить с другими стартапами не могу. Тз? Не, не слышали. «Но вот в следующем проекте обязательно будет». В стартапе иногда весело, прикольно и даже бывает полезно. Когда я в такое вляпался, мне, как frontend-разработчику, была поставлена только одна задача: сделать красиво. Ни тз, ни дизайна, ни прототипа, ничего. Очень скудная, местами неактуальная, документация, постоянные недокументируемые «мозговые штурмы», из серии «а давайте здесь красным е****м!». Польза (и вред) для меня в полной свободе действий. Стек технологий — выбирай сам, дизайн — ну набросай что-нибудь, потом посмотрим. Прокачатся можно, но отсутствие контроля и инкапсуляция в себе, гугле и своем стеке, накладывает свой отпечаток отсутствием понимания своего уровня и правильности своих действий, об этом в статье впрочем упоминается. Мне кажется тут как повезет. Если стартаперы компетентны, то все может быть неплохо, и для стартапа и для вас. Если же нет, то тучи могут сгуститься над всеми.
Возможно для прототипа и так нормально, а если стартап взлетит, то появится и ТЗ и стек и многое другое.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Изменить настройки темы

Истории