«Будь-яка пригода має з чогось розпочатися…

банально, але навіть тут це правда…»

Л.Керрол. Аліса в країні див.

Отже, давай уявимо.

Нова робота в новій компанії. Ти прийняв (ла) оффер. Працюєш уже кілька днів або тижнів і намагаєшся зрозуміти, куди ти потрапив(ла). Чого чекати від співробітників та керівництва? Як будувати відносини з оточуючими?

Як це зробити?

Мені, як кібернетику, не спало на думку нічого іншого, ніж використати запропоновану ще у 1937 році Карлом Людвігом фон Берталанфі в його загальній теорії систем ідею, віднести саме цю окрему компанію до якогось загального класу систем, а потім знайти опис таких систем (більше про фон Берталанфі можна почитати, наприклад тут, а про теорію систем тут).

Тобто, я хочу використати поради розумних та досвідчених. Швидше за все, люди вже напрацювали певні висновки щодо того, як себе вести в тих чи інших ситуаціях, перебуваючи в тих чи інших компаніях. Класифікували ці напрацювання. Треба тільки пошукати ці класифікації і зрозуміти, до якого класу відноситься «твоя» компанія.

Нижче я наведу кілька класифікацій (моделей), які, на мій погляд, є корисними для розуміння оточення. Відзначу, що це лише мій погляд і мій досвід використання. Кожен може використовувати власні підходи: від гороскопів і нумерології, до ще більш "просунутих" підходів.

Отже, перше, про що хочеться поговорити — це про кольорові організації.

Якщо постояти де б то не було досить довго, за тобою вишикується черга.

«Закони Мерфі, та пов'язані з ними висновки»

Сегодня хотел бы поговорить о разработке и поддержке. Поделиться, как мне кажется, удачным примером борьбы с потоком важных и срочных задач, которые нужны на вчера… Точнее с созданием правил работы с рутинными задачами разработки.

Правил, которые позволят отвлекаться на рутину только в случае каких-то отклонений.

В споре рождается истина... но иногда умирает здравый смысл.

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

Работать с людьми - это самое сложное. Ну, по крайней мере, для меня.

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

Поощрять инициативность, самостоятельность, но не давать всему этому переходить в самоуправство и раздолбайство.

В моих командах всегда очень много профессионалов своего дела. В своих сферах они всегда на 200% разбирались лучше меня - умные и самодостаточные сотрудники.  Поэтому "включать начальника" чаще всего не получалось. Приходилось искать решения и вырабатывать линии поведения - потеря человека на проекте - это всегда лишний головняк, который никому не нужен.

Ниже несколько моих правил-принципов, наработанных опытным путем.

Сегодня еще один материал на околопсихологическую тему. "Около", потому, что это очень сложная сфера знаний, которой нельзя вот так вот заниматься набегами. Я ею и не занимаюсь, а просто использую некоторые материалы для объяснения своего отношения к тем или иным вопросам. 

Так вот...

Сейчас в сети можно найти огромное количество материалов вида "Правила успеха Стива Джобса", "10 правил жизни Билла Гейтса"...

Истории успешных и знаменитых публикуются, продаются.

У каждого своя история. Уникальная.

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

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

Несмотря даже на то, что "на ошибках учатся" или даже "дурак учится на своих ошибках, а умный на чужих". Истории об ошибках мало кому интересны.

Миллионы подражают Стиву Джобсу, но компания Эппл такая одна.

Миллионы хотят создать Майкрософт, но только Билл Гейтс последнее время лидирующие позиции в списке самых богатых людей мира.

Почему так?

Этот пост не имеет ничего общего с фильмом про Шурика, и он не про опыты над животными.

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

Когда провожу собеседование с соискателями на руководящие должности, к своему удивлению довольно часто сталкиваюсь с ситуацией, когда человек не имеет опыта руководителя, но хочет попробовать. На нас. (Иди лучше тренируйся вон на… на кошках).

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

Так вот, так не бывает.

"Невежество чаще порождает уверенность, чем знание"

Ч. Дарвин

Когда я решил здесь описать об эффекте Даннинга-Крюгера, я думал, что это будет очень короткий пост со ссылкой... или сслыками. Но, не вышло. Банальные ссылки на Вики не давали всего того, что я хотел бы донести. А хорошие материалы были равномерно "размазаны" по нескольким статьям, причем часть из них в переводе я не нашел (ну, или плохо искал). И пришлось вспоминать студенческие годы и "делать самому". Рерайтинг чистой воды. Но, как мне кажется, качественный и от этого полезный. А может это у меня проявления эффекта Даннинга-Крюгера?

Итак, исходники: материалов находятся здесь, здесь и здесь. (Есть еще ссылки по ходу текста, плюс определения из Вики)

Материалы на итальянском, английском. Но, Гугл переводчик в помощь. Не хочется? Тогда жмем "подробнее".

Это будет, в целом, очень очевидный для многих пост.

Но иногда простые вещи оказываются настолько простыми и очевидными, что мы их не замечаем в погоне за решением той или иной задачи.

Поэтому немного "капитана очевидности" для тех, кто думает о том, как строить структуру ИТ разработки.

Итак. Как должно быть?

В не ИТ компаниях, в общем, существует 3 функции, касающиеся разработки программного обеспечения:

1. Программисты
2. Специалисты поддержки
3. Аналитики.

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

И еще парочку не связанных с ИТ. Это норма не только для ИТ: в небольших компаниях один бухгалтер и ЗП считает, и платежами занят, и отчетность сдает...

С ростом компании все больше появляется специализации.

Сколько раз сталкивался сам, не всегда вовремя останавливаясь.
Сколько раз останавливал других (а сколько раз не успел).

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

Не сложно навести порядок в списке пользователей (AD каталоге, списке юзеров в информационной системе).

Запросили у кадровиков должности, подразделения.

(Допустим не сломали мозг об совместителей, декретчиц и пр. Допустим повезло и в кадрах есть управленческая структура).

И лихо взялись наводить порядок.

СТОП!

А что будет завтра? С этим наведенным с таким трудом порядком?

На мой взгляд,наиболее точно и четко определение новизны дано вот здесь.

А то, что приведено в разделе "Новизна" на этом сайте, более отвечают направлению "новим для мене стало".

Ниже правдивая история о том, как родился этот "термин".

На одной из предзащит кандидатской диссертации соискатель бодро перечислял свои достижения.

Он был самоуверен, бодр и весел.

Выходило складно, по крайней мере так казалось нам - молодым аспирантам: везде сплошные достижения.

И тут у него "разработан новый метод", и там "впервые применена новая актуальная разработка"... 

Лучше один раз увидеть, чем сто раз услышать.

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

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

Ага, да, конечно (три утверждения подряд, но смысл ровно противоположный)... 

Это было напрасно потраченное время. Взамен которого у нас появится опыт, который, как мы знаем, бесценен.

Итак, когда видеоинструкция - это зло:

Правильное техническое задание (оно же ТЗ) - какое оно?

Грубо, оно должно содержать ответы на 2 вопроса:

1. ЧТО мы хотим получить?

2. КАК это должно быть сделано?

Т.е. состоять из двух больших частей. 

Очень часто сталкивался с тем, что в отдел разработки заходили "типа ТЗ", в которых была только первая часть. Описание того, что хотим. Иногда с умными формулами, эскизами страниц, диаграммами процессов...

Мы их называли "хотелки".