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

Не бывает «так получилось», бывает только «так сделали», — я писал об этом лет 11 назад.

Руководитель в живой гибкой организации обязательно характеризуется тем, что он адекватен в своих действиях именно для того, где находится и чем занимается. Это закон. Почти как гравитационный. Вам не нужен человек в команде, который делает не то что нужно. И более того — вы задаете условия того, что делать подчиненному, тоже высокому руководителю, но более мелкому чем вы, и в какой ситуации находиться. И ему отчитываться перед вами, а перед тем, кто ниже нет. И объяснять свои действия тем, кто ниже не обязательно, а часто вредно.

Нет никакого смысла в апелляции к проблемам более высокому руководителю, чем лицу непосредственно ответственному. Потому что более вероятно что видимые проблемы это проблемы созданные тем, кто кажется что должен навести порядок, чем тем, что что-то было не учтено, но от вашей информации обнаружится ошибка и исправится.

Тэги: решение, руководство, организация

---

Пост про универсальный механизм решения задач — http://evgenypupov.plya-plya.ru/note83/ — был присказкой перед другой мыслью, которую я хотел сказать.

Иногда поступают предложения сделать лекции по программированию или автоматизации.

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

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

Я бы сказал так: любая формализуемая задача может быть решена любым человеком, даже сорокалетним стоматологом, если он на подходящем задаче инструменте ИТ-разработки как можно быстрее научится получать обратную связь от того, что он делает. Вопрос времени. Каждому человеку в зависимости от его бэкграунда и навыков понадобится свое время. Но любой человек может научиться и сделать. Нет ничего невозможного в том чтоб написать Фэйсбук или Телеграм для любого человека, нормально справившегося со школьной общеобразовательной программой.

Установив и открыв любой инструмент разработки можно сразу начать что-то делать. Книги и вводные статьи покажут, как сделать какие-то элементарные вещи. Приступая к своей задаче, нужно как можно быстрее начать использовать что-то работающее из того, что вы узнали, и постоянно отслеживать результат своих действий, выводя информацию в консоли, алерты, окна сообщений, файлы — что удобнее. Информацию о значениях переменных, информацию о том что цикл зашел в отлаживаемую ветку, свойства объектов.

В этом будет настоящая информация, на основе которой можно делать настоящие стопроцентно корректные выводы, быстро корректировать действия и быстро проверять.

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

Тут еще отмечу что настоящие чистые программисты чаще всего работают не так. Они реально просто кодят: переводят сформулированную задачу на получеловеческом языке от аналитика в язык разработки, и отдают задачу на тестирование. Отсюда необходимость в тестировщиках и на мой взгляд низкое качество работы чистого разработчика.

Обратная связь из-за своей простоты и надежности информации в случае с задачами ИТ-разработки — это большой усиливающий эффективность рычаг. Но это не все. И даже ничего. Если не пытаться успешно проходить цикл процесса решения задач в целом. Все компоненты цикла важны и многогранны. Каждый может тянуть на десятки публикаций. Или сотни. Или как любовь на бесконечное количество публикаций.

1. Стремление к ценному:
— Если вам будет неинтересна ваша задача, рано или поздно вы остановитесь в длительном пути (если это серьезная задача) ее решения.
2. Наблюдение за ситуацией требующей решения:
— В рассматриваемом случае это и есть обработка обратной связи в чистом виде. И тем она хороша при разработке, что ее можно получать сразу от своих действий, а внешний фактор среды довольно мал по сравнению с задачами другого рода.
3. Ориентация где ты находишься и какие у тебя возможности:
— Очень важно адекватно оценивать обратную связь и себя. Можно начать раздражаться от того, что что-то не получается. Или решить что то, что происходит — чудеса и этого не может быть. Но это все контрпродуктивно. В случае с ИТ это точный интрумент. Тут все четко и чудес не бывает. Скорее всего вы делаете неверные выводы, но почему-то довольствуетесь ими. Если переоценивать свои возможности, ничего не получится из-за пришедшего рано или поздно разочарования. Не видя своих возможностей, даже вначале малых но имеющихся, тоже ничего не получится.
4. Принятие решения:
— Получив информацию о своих действиях и оценив возможности, нужно принимать решение что делать дальше: менять код, получить больше информации, воспользоваться справочником.
5. Действие:
— Реализовывать принятое решение. Продолжать улучшать ситуацию и работать.

Тэги: решение, задача, производительность, программирование, разработка, тестирование, аналитика, обратнаясвязь, эффективность, развитие

---

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

Цикл примерно такой:
Стремления к чему-то значимому — наблюдение за ситуацией требующей решения — ориентация где ты находишься и какие у тебя возможности — принятие решения — действия.

Этот цикл придумал не я. Искренне завидую тем, кто сам его полностью сформулировал. В литературе можно наткнуться на описание в разных вариациях. Он есть у Далио в своем виде. В некотором виде это OODA, популярная в управлении проектами. Не может быть сомнений что вокруг этого есть мысли еще во многих других книгах.

Слабые места для каждого человека при работе внутри этого цикла могут существенно отличаться. Кто-то делает лучше что-то одно, но в другом полная просадка. На каком-то этапе больше иллюзий и предубежденности, на каком-то меньше.

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

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

Можно угадать на каждом этапе наиболее адекватное прохождение. Тогда результат можно назвать удачей или талантом.

Тэги: мысль, цикл, решение, задача, эффективность, действие, обратнаясвязь, удача