Практическое Руководство ИТ-Лидера. Раду Спатару
друга и как действовать во многих стандартных и нестандартных случаях.
Почему важна ИТ Культура или ИТ-манифест?
Например, простые сообщения типа «Они меня не понимают» можно заменить на «Я могу их поддержать, я могу их научить понимать меня и/или мою работу».
Вместо того, чтобы сказать: «Я делаю свою работу. Они будут делать свою работу» мы можем изменить на «Мы в команде. Мы в одной лодке. Когда я заканчиваю свою работу, я могу помочь своим товарищам по команде или другим командам».
Не имеет значение, речь идет про коллег из Бизнес или ИТ подразделений? Я могу помочь им сделать свою работу должным образом.
Примеры такой поддержки:
Очень часто, то что делает команду или компанию эффективной, находится как бы «между задачами». Между задачами, которые выполняются разными людьми.
К примеру, сотрудник создал API, а другой сотрудник должен протестировать этот API. Тот, кто разработал, может сделать так чтобы сотрудник который будет тестировать, будет иметь всё нужное для этото, как бы построить «мост» (документация, пример как API работает и как протестировать).
Если раньше подобные задачи отнимали много времени, сегодня существует множество инструментов, в том числе с помощью ИИ, которые создают документацию для вашего API. И проще сделать API, проверить документацию и понять, правильно ли все работает или нет. Проверьте себя, по крайней мере, один или два раза, чтобы убедиться, что API работает правильно и документация полноценная. И, только после этих шагов передайте эту задачу QA-инженеру. Тем самым вы обеспечите беспрерывность работы, профессиональное исполнение работы а также удовлетворение от проделанной работы.
То же самое можно сказать и о сотруднике, который выполняет, к примеру – плановое техническое обслуживание в ночное время. Обычно такие работы выполняются во время наименьшей нагрузки из-за критичности изменений – для того, чтобы снизить риски потери сервиса и, в случае потери сервиса, иметь достаточное время восстановить сервис без негативного влияние на клиентов.
После окончания работ сотрудник должен написать короткую информацию/отчет:
– Было сделано такое изменение в этой платформе или системе, и описать что было сделано и почему: установлено новое программное обеспечение, обновление или исправление.
– Написать что проверялось после окончания работ и кто проверял (желательно с ссылкой на План Тестов).
– Что делать, если что-то работает не так.
– Кто будет заменять данного сотрудника после окончания ночных работ?
– Описать процедуру отката для критических ситуациях.
Таким образом каждый сотрудник не только закончит свою работу должным образом, но и поможет другим сотрудникам делать свои дела правильно и эффективно.
Как часть культуры ИТ, я хотел бы подробнее остановиться на двух важных процессах. Даже в крупных компаниях это процессы часто либо не выполняются, либо не выполняются должным образом: речь пойдет