20 вересня 2021 18:00
Работаю проджект менеджером на проекте Finline
Очень удивил отзыв от Евгения ниже.
Отвечу на комментарии касающиеся работы в компании и в команде.
Так как Евгений уже несколько раз менял свой отзыв, то нумерация пунктов и их названия могут не совпадать.
-----------------------------------------------------------------------------------------------------------------
Описание проекта:
Да, проект сложный, как упомянул ниже Евгений «в проекте — очень много связей, статусов, сущностей, зависимостей, сложных финансовых отчетов, таблиц, сводок и сверок, выгрузок и т. д., для этого и была открыта позиция Team Lead, а не Junior.
Изначально поиск и упор был на человека с большим багажом знаний, который за первые 2 месяца реализует оговоренные задачи, проявит себя как человек дела, а после получит полный карт бланш над проектом.
Что из этого сделал человек оставивший данный отзыв, будет перечислено ниже.
-----------------------------------------------------------------------------------------------------------------
Компания:
Комментарий про токсичность командного(корпоративного) чата
Евгений несколько раз делал репосты и публикации статей про вред вакцинирования от Covid-19, все разговоры были только про это.
Около 10 коллег попросили не публиковать эти новости, т.к. эта тема такая же провокационная, как темы про политику и религию. В чате можно общаться на любые другие темы, кроме тех, которые являются явно конфликтными.
-----------------------------------------------------------------------------------------------------------------
Состояние проекта и процессы:
1) Процессы на проекте отсутствуют от слова совсем. Всем плевать на проект, он никого не интересует
Над проектом работает команда из более 20+ людей, половина из них уже более 3 лет развивает проект. Кому «всем плевать» и для кого проект «никого не интересует» для всей нашей команды остается загадкой.
2) Когда нанимали сказали, что я должен действовать больше как Разработчик, а не менеджер, чтобы заслужить доверие команды, показать себя и получить доступы.
При обсуждении сотрудничества с Евгением были описаны основные задачи на период 2 месяца с критериями выполнения. Данные задачи были согласованы с Евгением и приняты им. Евгений не выполнил задачи, о которых мы договорились.
Код ревью на первых парах делал другой дев, который систематически начал замечать ошибки в merge request Евгения. В связи с чем было принято решение продолжить деплои в такой последовательности. Но чем дальше, тем становилось больше ошибок. Хромала как техника написания кода, так и грамматика знания англ. языка, но о грамматике я уже написал выше.
3) в youtrack я не мог создать ни одной задачи, вываливалась ошибка).
Евгений ни разу никому не сообщил о том, что у него нет возможности создавать задачи.
4. На проекте полностью отсутствовало соблюдение каких-то принципов разработки и проектирования, а те процессы что были скорее для видимости. — Все соглашение по Gitflow и branch naming и прочему были описаны на Confluence, куда Евгений зашел 1 раз, при выдаче ему доступа туда.
5. Хардкорные задачи (огромные и непростые) — я такие задачи люблю. —
На планировании спринта, когда продакты презентовали задачи и на разборе этих задач он говорил: «Да, это интересная задача, ставьте на меня». При этом он не читал описание, что нужно сделать в этой задаче, не задавал вопросов, не было оценивания. Когда ему задавали вопрос: «Евгений, тебе всё понятно, что нужно сделать в задаче ? Можем переходить к оцениванию?», ответ был один на все задачи: «Так я не могу сейчас её оценить, мне нужно сесть и всё прочитать и понять что там нужно». Так планирование спринта для того и предназначено, чтобы уточнить задачи, оценить сроки.
Его подход простой: «Просто ставьте на меня, а я сделаю», подход подвальной разработки. По факту после реализации, то что он сделал и то что было в описании, не соответствовало
6. Проект выдаётся без начальных демо-данных, база пустая без связных данных, местами не хватает в базе столбцов и страницы не открываются, проект практически неоперабельный и нормально не тестируемый. Я 5 раз просил архитектора сдампить мне часть данных с прода, даже показывал программу, которая дампит данные частями. Готов был сам сдампить данные для удобства разработки и отладки, но доступов мне не дали и сами не сдампили (Всем плевать, задачу создать не можешь на твои прозьбы плевать).
Как я говорил в самом начале, проект очень сложный с большим кол-во связей, статусов, сущностей, зависимостей и прочего, из-за этого сдампить эти данные и на них тестировать фичи проблематично, всё это из-за того, что через
7. Понятия тех. долг отсутствовало вовсе. — Весь тех. долг оформлен в виде эпиков/тасок/багов в системе ведения проекта, что в его понятии «тех. долг» и как он должен выглядеть, остается загадкой.
8. Проект хакатон. Чтобы сделать задачу, надо хакнуть кучу мест в проекте, закомментировать часть кода, в базе создавать кучу связных данных (так как их просто Лень, тем, у кого есть доступ, сдампить с прода), что снижает скорость разработки, качество внедрения новых фич, и понятное дело увеличивает количество багов.
Интересная практика хакать кучу мест в проекте/закомментить часть кода, создавать кучу связей в базе и для чего это всё ?! для меня этот пункт остается загадкой. При том, что другие девы ничего из перечисленного не делают и багов после деплоев нет, но у Евгения после хаканья, либо возвраты, либо баги.
9. Откровенное саботирование процессов всеми участниками на проекте в большей или меньшей степени. — Этот пункт перекликается с п.1. Для нашей команды также остается загадкой когда и кем что-то саботировалось и ключевой вопрос «зачем».
-----------------------------------------------------------------------------------------------------------------
Agile для видимости
1. Выдаётся задача, ты её делаешь, но она легко может
2. Тестер может вернуть задачу на доработку лишь потому, что он не разобрался как надо тестировать
Про приемочное тестирование я уже говорил, у него полностью отсутствует опыт какой-либо, взял задачу, комментом скинул merge request, а дальше тестируй что хочешь, я даже наверное не удивлюсь, если он на деве у себя не проверял конечный результат.
------------------------------------------
Что мной было сделано практически на Должности Team/Tech Lead:
Давайте разберёмся что такое тимлид ?
Тимлид — это IT-специалист, который управляет своей командой разработчиков, владеет технической стороной, принимает участие в работе над архитектурой проекта, занимается ревью кода, а также разработкой некоторых особо сложных заданий на проекте.
Чтобы начать управлять командой разработки, как я ранее писал, решили сделать код ревью написанного кода им, сразу были замечены ошибки как в структуре написания кода, так и в знаниях англ. языка. Для понимания название тега было написано с грамматической ошибкой. Исходя из ошибок решили ещё неделю ревьюить его код, ошибки не ушли и команда не доверила ему ревьюить их код и передать ему эту функцию как лиду. Про то как он отдавал задачи в тестирование я написал выше.
1. Проанализирован проект (большая его часть)
Как я и писал выше, мы договорились с Евгением о задачах на период первых 2 месяца. В них не было задачи проанализировать проект и дать рекомендации по его изменению.
2. Мной составлено 74 UML-диаграммы
Возможно, они есть, но, к сожалению, данные диаграммы никто не видел кроме Евгения.
3. Я проделал титанический труд (наверное один из самых больших за свою карьеру), его даже не захотели посмотреть и оценить....
Как я писал выше — 6 задач за 2 месяца, в среднем
4. Периодически оставался после работы, чтобы делать задачи, иногда работал дома допоздна.
-----------------------------------------------------------------------------------------------------------------
Прокомментирую его работу в целом:
а) Все его задачи, которые он делал, возвращались на доработку от 6 до 12 раз!
б) Приемочное тестирование. Для него либо неизвестно что это, либо он специально этого не делал. Всё, что не тестировалось QA, всегда сопровождалось кучей вопросов, на которые он отвечал в контексте «ты не знаешь как тестировать?».
в) Общение с заказчиком порой сопровождалось матом, либо разговор заканчивался ответом «ладно забей». Таким был ответ Евгения заказчику на вопрос что ты сделал и как это работает, когда его реализация отличалась от того, что было изначально написано в задаче.
Также хочу еще раз акцентировать внимание, что ниже отзыв от человека, который на позиции Team Lead за 2 месяца сделал 6 задач.
Ув читатели, что бы вы понимали данный пост 100% враньё, кроме моментов когда я писал про COVID и писал я вещи вполне аргументированные — почитайте если хотите..
Срегей Башмаков врёт в мою сторону раскрывается в этом комментарии:
jobs.dou.ua/...ies/treeum/reviews/50641
P/S
1.
Серёга ты вообще на работе не появлялся, я в отличии от тебя приходил к 11 и работал на совесть, а к 11 приходил потому что сидел на UML Диаграмами до
Я очень сомневаюсь что ты вообще хоть раз задержался и работал в
Чиябы корова мычала.
В нормальных компаниях прийти на работу в 11 это норма.
2. «в) Общение с заказчиком порой сопровождалось матом»
я отпечатался 1 раз — там должно было быть слово «Едите» но каждый думает в меру своей распущенности.
3. «Евгений ни разу никому не сообщил о том, что у него нет возможности создавать задачи. »
Несколько раз говорил на стендапе и писал в Телеграм. Врёшь ай ай стыдно будет если я опубликую скрины.
«Мной составлено 74 UML-диаграммы
Возможно, они есть, но, к сожалению, данные диаграммы никто не видел кроме Евгения.»
Ая-яяй )) Я просил Олега посмотреть но он отказался, я Тане говарил что компания даже не попыталась оценить мой труд 1000 раз повторял ей
Единственный Кого заинтересовало они это Никита Гусленко.. и то после отзыва маего.
1 коментар
Підписатись на коментаріВідписатись від коментарівКоментарі можуть залишати тільки користувачі з підтвердженими акаунтами.