The post has been translated automatically. Original language: Russian
In aviation, I was responsible for ensuring that the right part was on board by the time work began.
Now I am responsible for ensuring that the developer has an answer to every question by the beginning of the task.
Oddly enough, it's the same job.
I used to plan the maintenance of the entire fleet: I drew up a schedule of work, compiled a list of what would be needed for them, ordered spare parts and tools. Now I am a system analyst in the IT products office of Astana Hub and I write technical statements. Three things moved with me from aviation.
The scheduler doesn't do the work — it makes it possible. The mechanic should not discover at the time of the start of work that the part is not in stock: this means that it is ordered in advance, adjusted for the delivery time. A good problem statement is the same set. The developer should not find out in the middle of the task that the answer to the method has not been determined, and the designer should not find out that there are no texts in three languages.
There is no "approximately". The part either fits the part number, or it doesn't fit. A similar one won't do, even if it looks the same. The same thing happens with the requirements: "the user sees the notification" does not pass by part number. What, under what condition, what if the condition is not fulfilled.
They serve according to their experience, not according to their refusal. In aviation, no one waits for a knot to break — there are intervals, and they are the law. In the product, this same work is called technical debt, and it has to be defended in disputes because "it also works." I still think the aviation approach is the right one, although I understand why it doesn't take root in the product.
Now about where all this applies. The office of IT products is made by alem gpt, a mobile application and the Astanahub portal. My part is the portal: a community where posts, vacancies, Hub Market, programs and gamification are written and read. I'm writing a separate series of posts about gamification — it's in my profile, there's an analysis of the mechanics from the inside.The team is small, and this is rather a plus: the decision is discussed in one conversation, rather than in three weeks of approvals.
And since it's about changing the industry. Applications for Tech Orda, a government program where tuition at an IT school is paid by the state, are now open on the portal. The application can be submitted until September 21.
I'm writing about this because I've been changing the industry myself.
If you also came to IT from a "heavy" industry, write down what you took with you. It seems to me that most often it is not knowledge that moves, but habit.
В авиации я отвечал за то, чтобы к началу работ на борту лежала нужная деталь.
Сейчас отвечаю за то, чтобы к началу задачи у разработчика был ответ на каждый вопрос.
Это, как ни странно, одна и та же работа.
Раньше я планировал техобслуживание всего парка: составлял график работ, собирал перечень того, что для них понадобится, заказывал запчасти и инструмент. Сейчас я системный аналитик в офисе IT-продуктов Astana Hub и пишу технические постановки. Из авиации со мной переехали три вещи.
Планировщик не делает работу — он делает её возможной. Механик не должен в момент начала работ обнаружить, что детали нет на складе: значит, её заказывают заранее, с поправкой на срок поставки. Хорошая постановка задачи — тот же комплект. Разработчик не должен на середине задачи выяснять, что не определён ответ метода, а дизайнер — что нет текстов на трёх языках.
Нет «примерно». Деталь либо подходит по part number, либо не подходит. Похожая не годится, даже если выглядит так же. С требованиями то же самое: «пользователь видит уведомление» по part number не проходит. Какое, при каком условии, что если условие не выполнилось.
Обслуживают по наработке, а не по отказу. В авиации никто не ждёт, пока узел сломается — есть интервалы, и они закон. В продукте эта же работа называется техдолгом, и её приходится защищать в спорах, потому что «оно же работает». Я до сих пор считаю авиационный подход правильным, хотя и понимаю, почему в продукте он не приживается.
Теперь про то, где всё это применяется. Офис IT-продуктов делает alem gpt, мобильное приложение и портал Astanahub. Моя часть — портал: комьюнити, где пишут и читают посты, вакансии, Hub Market, программы и геймификация. Про геймификацию я пишу отдельную серию постов — она у меня в профиле, там разбор механик изнутри.Команда небольшая, и это скорее плюс: решение обсуждается за один разговор, а не за три недели согласований.
И раз речь зашла о смене отрасли. На портале сейчас открыт приём заявок на Tech Orda — государственную программу, где обучение в IT-школе оплачивает государство. Заявку можно подать до 21 сентября.
Пишу об этом потому, что сам менял отрасль.
Если вы тоже пришли в IT из «тяжёлой» отрасли — напишите, что забрали с собой. Мне кажется, чаще всего переезжает не знание, а привычка.
Share
