13 отзывов

RSS
Оставить отзыв можно с подтвержденным аккаунтом.

Работаю проджект менеджером на проекте 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 раз просил архитектора сдампить мне часть данных с прода, даже показывал программу, которая дампит данные частями. Готов был сам сдампить данные для удобства разработки и отладки, но доступов мне не дали и сами не сдампили (Всем плевать, задачу создать не можешь на твои прозьбы плевать).
Как я говорил в самом начале, проект очень сложный с большим кол-во связей, статусов, сущностей, зависимостей и прочего, из-за этого сдампить эти данные и на них тестировать фичи проблематично, всё это из-за того, что через 1-2 дня данные изменились и тесты будут положительные, а при выливке будут конфликты и полезут баги. На момент работы Евгения, ДевОпсы занимались арендой и настройкой серверов под тестовое окружение.

7. Понятия тех. долг отсутствовало вовсе. — Весь тех. долг оформлен в виде эпиков/тасок/багов в системе ведения проекта, что в его понятии «тех. долг» и как он должен выглядеть, остается загадкой.

8. Проект хакатон. Чтобы сделать задачу, надо хакнуть кучу мест в проекте, закомментировать часть кода, в базе создавать кучу связных данных (так как их просто Лень, тем, у кого есть доступ, сдампить с прода), что снижает скорость разработки, качество внедрения новых фич, и понятное дело увеличивает количество багов.
Интересная практика хакать кучу мест в проекте/закомментить часть кода, создавать кучу связей в базе и для чего это всё ?! для меня этот пункт остается загадкой. При том, что другие девы ничего из перечисленного не делают и багов после деплоев нет, но у Евгения после хаканья, либо возвраты, либо баги.

9. Откровенное саботирование процессов всеми участниками на проекте в большей или меньшей степени. — Этот пункт перекликается с п.1. Для нашей команды также остается загадкой когда и кем что-то саботировалось и ключевой вопрос «зачем».
-----------------------------------------------------------------------------------------------------------------
Agile для видимости

1. Выдаётся задача, ты её делаешь, но она легко может 2-5 раз меняться — На планировании спринта при презентации и обсуждении задач, Евгений вопросов не задавал, всё было ему ясно. При реализации задачи и расхождении результата от требований которые были описаны в задаче, Евгений считал это изменением задачи. Изменения в задаче — это «подзадача», а неверная реализация — это не соответствие требованиям.

2. Тестер может вернуть задачу на доработку лишь потому, что он не разобрался как надо тестировать
Про приемочное тестирование я уже говорил, у него полностью отсутствует опыт какой-либо, взял задачу, комментом скинул merge request, а дальше тестируй что хочешь, я даже наверное не удивлюсь, если он на деве у себя не проверял конечный результат.
------------------------------------------
Что мной было сделано практически на Должности Team/Tech Lead:

Давайте разберёмся что такое тимлид ?

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

Чтобы начать управлять командой разработки, как я ранее писал, решили сделать код ревью написанного кода им, сразу были замечены ошибки как в структуре написания кода, так и в знаниях англ. языка. Для понимания название тега было написано с грамматической ошибкой. Исходя из ошибок решили ещё неделю ревьюить его код, ошибки не ушли и команда не доверила ему ревьюить их код и передать ему эту функцию как лиду. Про то как он отдавал задачи в тестирование я написал выше.

1. Проанализирован проект (большая его часть)
Как я и писал выше, мы договорились с Евгением о задачах на период первых 2 месяца. В них не было задачи проанализировать проект и дать рекомендации по его изменению.

2. Мной составлено 74 UML-диаграммы
Возможно, они есть, но, к сожалению, данные диаграммы никто не видел кроме Евгения.

3. Я проделал титанический труд (наверное один из самых больших за свою карьеру), его даже не захотели посмотреть и оценить....
Как я писал выше — 6 задач за 2 месяца, в среднем 2-3 sp оценка одной задачи.

4. Периодически оставался после работы, чтобы делать задачи, иногда работал дома допоздна.
2-3 раза остался до 20-21. При этом на работу Евгений приезжал к 11.
-----------------------------------------------------------------------------------------------------------------
Прокомментирую его работу в целом:

а) Все его задачи, которые он делал, возвращались на доработку от 6 до 12 раз!

б) Приемочное тестирование. Для него либо неизвестно что это, либо он специально этого не делал. Всё, что не тестировалось QA, всегда сопровождалось кучей вопросов, на которые он отвечал в контексте «ты не знаешь как тестировать?».

в) Общение с заказчиком порой сопровождалось матом, либо разговор заканчивался ответом «ладно забей». Таким был ответ Евгения заказчику на вопрос что ты сделал и как это работает, когда его реализация отличалась от того, что было изначально написано в задаче.

Также хочу еще раз акцентировать внимание, что ниже отзыв от человека, который на позиции Team Lead за 2 месяца сделал 6 задач.

Прокомментирую отзыв Евгения ниже.

Мы договорились с Евгением о сотрудничестве с ним как Team Lead PHP Developer.
За 2 месяца, которые как компания, так и сотрудник, берут для себя, чтобы понять подходят ли они друг другу, мы определили сотрудничество как неуспешное.

Причины:
1. Невыполнение поставленных задач, о которых договорились при старте сотрудничества (большое количество задач возвращались на доработку 5+ раз, некоторые задачи вообще не взялись в работу, невыполнение роли Team Lead).
2. Обвинение других членов команды в том, что Евгений не выполнил задачи: бизнес-аналитик (который плохо описал задачу), проджект-менеджер (который плохо ведет беклог или оценивает задачи), другие разработчики.
3. Обесценивание работы других членов команды, которые работают над проектом уже 5 лет. А также явная неготовность работать в команде. По словам Евгения нужно всех уволить и предоставить ему возможность переписать все самому до 2023 года.

По итогам 2-месячного сотрудничества я провел с ним обратную связь, обсудили выполнение задач. Евгений согласился, что не справился с задачами: «Да, я на 100% не справился с ролью Team Lead», после этого мы без взаимных претензий и обид договорились прекратить наше сотрудничество. Евгений напоследок сказал: «Жаль, мне понравилась Ваша компания, я уже начал привыкать».

Работал на должности: Team/Tech Lead PHP / Срок: 2 месяца / Проект: Finline

SENIOR / LEAD — Не идите сюда, украинское болото без процессов. Уверяю вас: вы ничего не потеряете, если пройдёте мимо, меня уволили без анализа моей работы, так как проанализировать и оценить вас адекватно не смогут. Читайте отзыв и поймёте почему.

За свою 15+ лет карьеру в Международных компаниях я был впервые уволен Украинской компанией, за несоответствие занимаемой должности.

Очень жалею, что потратил 2 месяца своей жизни на данную компанию.

-> Плюсы лично для меня:

1. Отличный мастер над печеньками.
2. Удобное расположение офиса на Петровке (Почайна).
3. Реально очень гибкий график работы (то что меня подкупило). Стендап можно было проводить даже за рулём авто и это норма очень меня устраивала.
4. Сложные хардкорные задачи, над которыми надо реально сидеть, включать мозги и напрягаться, задачи сложные, бросающие вызов воли.
Больше плюсов нет.

-> Минусы лично для меня:

1. Жуткий токсичный чат внутри компании, вас сразу смешают с говном, если ваше мнение отличается от мнения большинства, а если вы его выскажите в чате, вас могут удалить.
Я решил удалиться сам.
2. Невежество, безразличие, ЧСВ заоблачное, особенно у Олега (владыка).
3. При онбординге даже чашку не выдадут — позор!

P.S Посмотрите как другие компании встречают людей: dou.ua/...​ta/articles/welcome-pack

---------------------------------------- Развёрнутый Отзыв (чтение 2 мин.) ---------------------------------------------

-> Описание проекта:

В проекте очень много связей, статусов, сущностей, зависимостей, сложных финансовых отчётов, таблиц, сводок и сверок, выгрузок и т. д. Проект огромный, местами сложный, плохо операбельный, сложные архитектурные и технические ошибки, безразличие команды по многим вопросам, кодовая база просто дно! Гигантские куски копи паста которые не делаю не чего кроме богов, не кто не знает что это и для чего. Я промолчу про Базу данных и её организацию....

-> Проект просто фарш.

1. Процессы на проекте отсутствуют от слова совсем. Всем плевать на проект, он никого не интересует, именно поэтому меня и наняли, чтобы я привёл там всё в порядок (я так думал).
2. Когда нанимали сказали, что я должен действовать больше как Разработчик, а не менеджер, чтобы заслужить доверие команды, показать себя и получить доступы. Чтобы было понятно: я даже не мог делать код ревью (мог только какими-то варварскими способами, нормального флоу нет, не было доступов, в youtrack я не мог создать ни одной задачи, вываливалась ошибка). Доступы должны были дать после испытательного срока, так мне сказал Никита Гусленко (Архитект).
3. На проекте не было докера под локальную среду, не было дев/стейдж сервера, всё сразу шло в прод и там тестировалось, всем плевать на проект.
4. На проекте полностью отсутствовало соблюдение каких-то принципов разработки и проектирования, а те процессы что были скорее для видимости.
5. Хардкорные задачи (огромные и непростые) — я такие задачи люблю.
6. Проект выдаётся без начальных демо-данных, база пустая без связных данных, местами не хватает в базе столбцов и страницы не открываются, проект практически неоперабельный и нормально не тестируемый. Я 5 раз просил архитектора сдампить мне часть данных с прода, даже показывал программу, которая дампит данные частями. Готов был сам сдампить данные для удобства разработки и отладки, но доступов мне не дали и сами не сдампили (Всем плевать, задачу создать не можешь на твои прозьбы плевать).
7. Понятия тех. долг отсутствовало вовсе.
8. Проект хакатон. Чтобы сделать задачу, надо хакнуть кучу мест в проекте, закомментировать часть кода, в базе создавать кучу связных данных (так как их просто Лень, тем, у кого есть доступ, сдампить с прода), что снижает скорость разработки, качество внедрения новых фич, и понятное дело увеличивает количество багов.
9. Откровенное саботирование процессов всеми участниками на проекте в большей или меньшей степени.

-> Компетенции кадров на проекте:

1. Я в первый рабочий день сразу нацелился создать дев/стейдж сервер, я предложил вариант, что сам настрою и разверну проект через Gitlab CI/CD, что я настрою runner и весь процесс деплоя для дев ветки. И вот когда я уже настроил докер для локальной среды разработки, был «арендован» дев сервер (мне как лиду не дали туда доступы). Дальше мне сказали, что у нас есть девопс и вот пусть он и настраивает. Девопс настраивал сервер 2 недели, а в итоге, когда я зашёл в ветку протестировать новое окружение оказалось, что окружение сделанное девопсом, неоперабельное. Всё что сделал девопс — надёргал куски из моего докера и добавил редми, установил Task вместо моего Makefile. По факту локальное дев окружение перестало работать, а дев/стейдж не появилось.
Задача подразумевала просто создание дополнительного docker-compose-stage.yml + папки docker/stage, в которой будут докер файлы для билда окружения. В итоге задача обсуждалась на стендапах, а потом про неё все забыли и она так и не была сделана, мои попытки напоминать о задаче были без успешными.

Получается мне сделать не дали и сами не сделали — виноват Лид.

2. Продукту я предложил ввести Эпик по тех. долгу (переписыванию/ переработке/ рефакторингу), скидывать туда задачи и накопить базу задач по тех. долгу. Я скинул ему в телеграм предложение, чтобы он оценил, подправил, высказал своё мнение, возможно ответил сколько времени есть на тех. долг, чтобы начать планирование спринтов с тех. долговыми задачами. На предложение мне ответили: «Я на созвоне, после созвона гляну». До сих пор смотрит...

3. Просил Олега(владыку) рассказать мне, что он хочет в каком качестве, позже я ему написал в телеграмм, он обещал после со звона вдумчиво прочитать и ответить, так и не ответил, позже я писал ещё раз ему он обещал поговорить со мной и всё рассказать — но так времени и не нашёл.

Когда со мной «Прошались» Олег сказал ну раз тебя все игнорят чего ты мне не написал ? :)

-> Agile для видимости

Как происходит оценка сторипоинтов ? Никак!

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

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

-> Что мной было сделано на Должности Team/Tech Lead:

1. Проанализирован проект (большая его часть), разработана система и рекомендации для всех участников (PM, QA, BA, DEV) по внедрению и улучшению процессов. Понятно, что сходу внедрить супер уровень не получится. Надо чтобы процесс был постепенный и все привыкли без напрягов. Была разработана программа на 3 месяца по постепенному улучшению процессов, к сожалению, владыка, когда увольнял меня сказал, что ему неинтересно оценивать мои переписки и предложения, а также попытки что-то сделать. Когда я попросил оценить мою работу, получил отказ, попытаться договориться не получилось.

2. Мной составлено 74 UML-диаграммы по узлам проекта, по логике и структурам данных, по тем местам, с которыми я разбирался и работал. Это задел для глубокой переработки и улучшения кодовой базы проекта в будущем.

3. Я проделал титанический труд (наверное один из самых больших за свою карьеру), его даже не захотели посмотреть и оценить....

4. Периодически оставался после работы, чтобы делать задачи, иногда работал дома допоздна.

-> Вывод

1. Адекватно оценить не смогут, провести аудит работы не интересно.
2. Ты должен сидеть в проекте с низкой кодовой базой и «гавнокодиться» и делать «гавноревью» и имитировать деятельность, умеешь хорошо имитировать рабочие процессы то ты тут задержишься, так как кодовая база низкого качества, ввести CSFixer или PHPStan не реально.
3. При попытки что-то делать будет тотальнейший игнор по всем фронтам.
4. При попытки нанять моих знакомых, мне Никита(Архитект) сказал что он будет решать куда их распределять, а не я как ЛИД, я должен был работать с людьми которые меня игнорят и им всё ровно или с проверенными людьми не одним проектом ? Серьёзно ?

Рекомендую всем кто захочет устроиться на проект Finline задуматься трижды!!!

Є стаття Як працювати на роботодавця із Дія Сіті (копія)

В статті згадується назва компанії яка схожа на вашу:

З хорошого — Дія Сіті виглядає достатньо пристойно та перспективно
Валерій Любарський, адвокат, за підтримки Юридичного департаменту TREEUM

Чи можете ви підтвердити інформацію про підтримку «Дія City»?

Відповідь на питання важлива для фахівців які підтримали петицію Стоп Дія Сіті! та петицію Стоп Дія Сіті! Ветування.

Всем привет! Крутая, амбициозная но адекватная компания, это редкость! Хороший офис на Петровке, парковка есть, большниство работает удаленно. Корпоративная культура то что надо ;) FinTech рулит.

Я в компании всего 3 месяца, но могу без преувеличения сказать, что это одно из лучших мест, где мне посчастливилось работать. Правильная корпоративная культура, гибкость и лояльность во всем, постоянная поддержка и множество плюшек, которыми вроде бы никого не удивишь, но все же приятно. А еще, как вишенка на торте — руководитель, который заботиться о твоем эмоциональном здоровье.
В общем, с Treeum у меня случилась любовь! Рада быть частью крутой команды)

В компании работаю почти пол года. За все это время не было ни дня сомнений на своем ли я месте. Максимально лояльная, гибкая и открытая компания в которой тебя ценят и прислушиваются к твоему мнению.

Работаю в компании более 6 лет! Компания очень стремительно развивается! Хорошая корпоративная культура которая способствует развития и положительному имиджу компании. Не напряжно а интересно. Коллектив очень открыт и всегда поможет. В компании есть множество бонусом, руководство лояльное и всегда идет на встречу сотруднику:) Приятно работать:)))

Працював у компаніі близько 8 місяців і хочу подякувати Сергію Віндерських за те що вмовив мене пройти школу дизайнерів бюро Горбунова. Це напевно, найбільший стрибок росту в кар‘єрі дизайнера інтерфейсів. Деколи було важко працювати на проекті finance.ua і водночас проходити курси з домашкою, та я ні разу не шкодую що так сталось. Дякую Сергію, що тоді на співбесіді вирішив мене взяти в команду. Успіхів компанії Treeum!)

Команда Триум_а приняла меня около 2ух месяцев назад. Меня взяли под новый проект, и дали время на обучение соответствующим фреймворкам. Теплая киевская зима, пробила мой иммунитет и я заболел. Что совсем не оказалось проблемой для начальства, меня любезно отпустили на 3 дня и пожелали выздоровления. Такие практики есть не везде, а здесь есть и это классно. К слову про начальство — руководитель всегда доступен, и ничего не мешает провести обсуждение какого-либо вопроса. Очень удобный менеджмент событий, если есть какое-либо мероприятие, на котором ты должен присутствовать. В комнате отдыха есть настольный футбол, пуфики, и массажное кресло. Активностей тоже полно, день именинника, корпоративы, праздники, на кухне почти всегда есть печеньки. Поздравления на день именинника индивидуальные, люди пишут персональный текст, и звучит очень круто, чувствуешь себя особенным. Рядом есть ашан, коллинс, вайкики, интерспорт, Городок. Целую зарплату домой унести невозможно.

Работаю в Триум уже год, испытательный срок проходил на стеке PHP backend. Я устраивался как бекенд разработчик. Позже перешел на проект со стеком Python. Кроме бекенд задач занимался еще фронтендом. Пришлось писать не только на Питоне но и на javascript как для фронта так и для бекенда на стеке Nodejs, в итоге вырос с бекенд разработчика в Fullstack разработка. После всего этого могу сказать, что в компании всегда есть куда развиваться и компания в этом способствует.

Работаю в Триум около года в Core team. Когда общался с hr, у меня сразу уточнили сколько было бы комфортно получать во время ис + услышали мои з/п ожидания,в итоге в оффере предложили даже чуть больше чем планировал. Да и ИС закрыли быстро, за 3 недели, что не могло не радовать.
Раньше я работал в аутсорс компании, в Триум мне дали время адаптироваться/ перестроиться на продукт.
Сейчас я один тестировщик на проекте, могу спокойно предлагать внедрять свои инструменты, какие хочу. Приятно, когда мою инициативу поддерживает руководитель. Идеи поддерживают и поощряют. + Руководитель проекта относится к каждому члену команды одинаково. Это круто, когда разраб/тестировщик/архитектор системы могут одинаково высказать свое мнение и к нему прислушаются.
Удобное расположение офиса, рядом есть спортзал, куда ходят много ребят с офиса, в обед можно сходить потренить.

Чудова компанія, привітний колектив, відношення на високому рівні, зручно розташований офіс. Супер!!

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

Администрация не совершает модерацию таких материалов, кроме как в случаях, прямо предусмотренных Правилами пользования вебсайтом (https://dou.ua/legal/). Администрация не уполномочена решать споры, которые возникают между пользователями или с третьими лицами, или быть стороной такого спора. В случае нарушения Ваших прав обращайтесь непосредственно к автору соответствующей информации или органу, компетентному решать споры/устанавливать факты подобного рода.