#мойстатус #знания

Я не знал, что меня ждет❗️(часть 2)

7️⃣ Инструменты и рабочие тулы
Jira, Confluence, Gitlab, Google Docs — нет! Тут этого не было. Slack и Bitbucket только были. И то, не особо ими и пользовались. Ребята юзали Azure DevOps, в котором у меня не было опыта от слова вообще, MS Teams, Office 365, в который входят различные продукты и сервисы от Microsoft (там же и почта Outlook, которую используем как оф. канал общения с клиентами), виртуальная машина — всё связано с Microsoft.
Поясню. Здесь в Эмиратах всё секьюрно, и местные власти предпочитают Microsoft (офис который у нас тут есть) Гугловским сервисам, секьюрность которых, кстати, чуть пониже Гейтсовских. Поэтому работа с отдельными файлами — это норма. И файлы грузятся в онлайн облако — OneDrive. Сбрасывать клиентам документацию не ссылкой на файл, а отдельным файлом. Да, вот так вот 🙂. Напомнило мне, когда я работал в банке, и бразуером пользовались Internet Explorer (до того, как он стал Edge). Приходится привыкать и адаптироваться.

Но нужно было как-то улучшить это положение. Что сделал я:
Создал пространство в Google Drive для компании, настроил, чтобы было удобно работать с файлами, покрутил настройки безопасности, дал доступы нашему менеджменту и разработчикам. Этот вариант был только для нашей компании. Но хоть как-то упростить работу.
Создали пространства компании в Jira и Confluence (как не крути, Jira удобнее и функциональнее Azure, а в Confluence удобнее хранить документацию о проектах в виде архива. Тем паче эти две тулы одной компании, секьюрность которой высокая).
Также, создал Time reports и обучил разработчиков корректно его оформлять. Один проект = один Time report. Но так как некоторые разработчики работали на нескольких проектах одновременно, пришлось один отчет создать общим, в котором они писали каждый день, каким проектом занимались, что именно делали и указывали количество часов, затраченных на работу. В дальнейшем, кстати, время трекать будем иначе, более точно, т.к. разработчики могут указать не реальные часы. Все это нужно для того, чтобы менеджмент понимал прозрачность работы и мог корректно считать зарплату, но и другие выплаты.

8️⃣ Митинги
Как я писал выше, соотношение разработчиков к проектам + малые сроки на некоторых проектах были проблемой. А в одном проекте настолько жесткий дедлайн, что частота встреч только отнимала бы время разработки и это реально боль. Взвесив все за и против, я решил внедрить только самые важные события: спринт (у нас недельный), стендап (раз-два в неделю), ретроспектива (раз неделю/две), PBR (это когда пересмотр бэклога и его наполнение — раз в неделю). Всё! И это работает. Демо не на всех проектах присутствует. Вероятно, такие взаимодействия с заказчиками были налажены до меня. Но на одном проекте, где заказчик не из гос. аппарата, я настраиваю процессы по канонам всеми нам знакомым практикам и использую нормальные подходы. Чего только стоит консолидация из требований задач и их эстимация (оценка) в соответствии с известными практиками. Разумеется и демо там есть.

9️⃣ Скорость работы, знания и взаимодействие
Буду краток, скорость работы пониже и знания похуже наших разрабов. Тут ничего не поделаешь. Однако взаимодействие в некоторых местах полегче будет, ребята тебя больше слушают и меньше включают своё эго, которое у нас раздуто в разы по сравнению с этими ребятами. Стоило бы поучиться.

Есть и слабая сторона — это отношение к работе: исполнительность, ответственность и упорство. По сравнению с русскоговорящими разработчиками эти качества страдают. Я уже не говорю про западных ребят (там эти качества чаще выше, чем у русскоговорящих программистов).
В общем, Восток, такой Восток. Тут нужен другой подход. Но не всегда и другой подход поможет. Если ты не завоевал сердце ребят и не заслужил доверие — считай, что расположить ребят не получится и ты будешь заниматься микроменеджментом.

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