Примечание: я работал аналитиком, поэтому буду вещать про свою предметную область. Не знаю, как у других.
1. Начну с главного - переработки. Да, это краеугольный камень Гриндаты, увы. Переработок много, они не оплачиваются, более того, переработки идут рука с новым сотрудником с первого дня его работы и до самого увольнения. При всём этом, я говорю не о том, чтобы пару раз в неделю задерживаться на час-другой и раз в месяц поработать в выходные. Нет, я говорю о том, что работать приходилось с девяти утра и до десяти вечера без обеда и каких-либо перерывов. Тестирование системы на выходных (или в праздники) - отдельная тема. Нужно потратить несколько часов на то, чтобы всё перепроверить, а уж если что-то отвалилось, нужно тратить бесконечное количество времени на то, чтобы это починить. Переработки носят системный характер, руководство (да и сотрудники) никак не пытаются с этим бороться.
2. Система, с которой предстоит работать, представляет собой БД с кучей разных примочек. Она тяжела, необъятна и переполнена миллионом несуразных сущностей, которые существуют исключительно для того, чтобы хоть как-то заставить работать процессы одного подразделения и не сломать процессы другого. Тем не менее, новые сущности, дублирующие старые, плодятся в геометрической прогрессии, о переиспользовании задумываются только тогда, когда об этом прямо просит заказчик. В результате - простые объекты системы снабжаются десятками лишних атрибутов и странных алгоритмов. Справочники, существующие в рамках одного проекта, абсолютно неприменимы в рамках другого даже если содержат идентичные значения (просто никто не додумался прикрутить версионирование или признак подразделения). Бизнес-процессы - кошмарный кошмар, мешанина из сотен алгоритмов непонятного назначения, которые пишутся одними отделами для того, чтобы не ломать работу других. Всё это подводит нас к заключительному пункту:
3. Погружение в процесс. Есть небольшой онбординг для новых сотрудников, однако система, повторюсь, сложна и перенасыщена, поиск взаимосвязей в ней тратит нереальное количество времени, которое можно было бы потратить на разработку и внедрение (при грамотном системного анализе, на который, увы, в Гриндате нет ни времени, ни специалистов). Ни одна доработка не рассматривается с точки зрения соприкосновения с существующими системными процессами, в сжатых сроках, выставляемых руководством, все ресурсы и время уходят на то, чтобы создать десяток костылей и показать заказчику, мол, всё работает. А потом повторить это при новой доработке, создав уже два десятка костылей. Такова, к сожалению, реальность.
Будучи аналитиком, я занимался чем угодно, только не аналитикой. Основной задачей было писать алгоритмы по обработке реестров данных (на джаве и SQL). Времени на то, чтобы изучить джаву и SQL (брали меня без этих навыков), мне, конечно же, никто не предоставлял, как и времени на то, чтобы разобраться с системой. В результате приходилось городить ерунду, чтобы хоть как-то отстреляться перед заказчиком.
В компании нет никакой лояльности к своим сотрудникам, если ты перед важным показом заказчику обнаружил, что функционал, который ты беспрерывно (вспоминаем про переработки) настраивал в течение последней недели, накрылся по вине доработки другого подразделения - это только твоя вина, и только тебе нужно искать виновных и единолично разбираться с проблемой. PM успешно перекладывает всю ответственность на других сотрудников и никогда не оказывает помощи. Что же касается рабочего коллектива, то и здесь всё очень печально. Часть сотрудников некомпетентны, у них просто нет времени ознакомиться с проблематикой и предложить технологии оптимизации процессов, они заняты лишь тем, чтобы настроить систему так, чтобы она не падала (что при этом происходит на бэке, заказчику никогда не сообщается). Другая часть откровенно озлоблена и надменна при попытке обратиться за помощью. Да, встречались люди, готовые помочь, но это была капля в море.
Отсутствие бюрократии - это, конечно, плюс, однако в Гриндате отсутствуют и спецификации, и пояснения, и тех. задания, и вообще всё, что можно было бы использовать при разработке. Весь процесс выглядит так - заказчик присылает ТЗ, а аналитик в кратчайшие сроки пишет ЧТЗ, описывая, как это будет работать в системе. ЧТЗ пишется сыро и поверхностно без оглядки на реальную ситуацию с системой, лишь бы было более-менее понятно разжёвано. Заказчик согласует ЧТЗ, и начинается разработка, в ходе которой становится довольно очевидно, что как минимум половина из описанного аналитиком в ЧТЗ нуждается в правке. И ЧТЗ правится бесконечное множество раз.
Подводя итог, мне не хотелось бы рекомендовать эту компанию в качестве трудоустройства даже на первое время. Мизерная заработная плата, чудовищные переработки, отсутствие документации, разрозненный коллектив - все эти недостатки никак не компенсируются достоинствами.
Желаю руководству Гриндаты провести-таки реинжиниринг ВСЕХ своих процесс, отстранить некомпетентных специалистов от работы, составить внятный онбординг и заново укомплектовать штат специалистами в предметной области.
