Это скилл сет, который требуется на позицию. Люди не роботы, и почти всем, кто видиь других людей и как-то общаеься с ними, нужны soft skills. Но это никак не делает архитектора психологом или, ну не знаю, лингвистом. Ну бред. Я говорю/пишу, просто в жизни? Я гуманитарий, потому что использую язык?
Я написал email. Бинго, я гуманитарий, я перенес мои мысли на "бумагу" а другой человек прочитал. Ну маразм же :)
Если я прочитал чужой код - ну я точно гуманитарий так как смог по наскальным письменная предшественника пофиксить его баг
Это навыки коммунакации, котррые человек использует задолго до того, как это стало "наукой" (в глазах некоторых).
К примеру, я делаю презентацию. Я часто это делаю. Я гуманитарий? Чо, правда?
Принимая во внимание популярную оценку стоимости решения, которая говорит, что прибавление одной 9ки приводит к добавлению одного 0 к сумме контракта, хочется заметить, что рекомендации как и чего построить без знания бюджета выглядят не очень корректно
Мне кажется, анкеты и прочее ... этим никто не занимается
Есть полезное упражнение. Ретроспектива. Оно есть в методичках по скраму и т.д. Его можно применять к себе для анализа что и как.
Для адекватного применения:
Надо пытаться слушать, что происходит вокруг и тогда можно узнать, что что-то идет не так
Надо искать причину в себе и пытаться понять, а что я мог слелать, чтобы вышло лучше
Но это никак не связано с описанным эффектом. Он просто констатирует статистически определенные паттерны поведения. Ну и тихонько так говорит "сомневайся и проверяй себя" )
Обычно и на одну компетенуию сложно найти человека, а тут на 5 условно :)
Скорее вы не зрелая компания, и это не обязательно плохо. Скорее хорошо, так как вы растете и вам нужны сейчас "единороги"
Теперь по ролям.
ПМ: по хорошему, этот человек отвечает за бюджет и сроки, а также за то, что результат работы соответствует ожиданиям заказчика/продакта. Да, у него есть много обязанностей и они перечисленны неплохо. Скрам-мастер - я лично считаю, что отдельный человек - это блажь, и возложение этой роли на ПМ - это хорошо. Но по большому счету, так и раньше было, просто многим захотелось попилить денег на консалтинге вокруг модных тогда слов и технологий
Аналитик - странно. Да, бывают ПМ, которые колупаются в требованиях больше необходимого. Это либо от безделья, так как проект и команда небольшие, либо потому что это бывший аналитик, которому забыли напомнить, что он уже не аналитик. ПМ должен в требованиях понимать взаимосвязь, критичность и цену реализации. Первое позволяет планировать и проверять, что все загружены и на ближайший спринт все логично. Второе - выстраивать приоритеты и делать более ценное раньше. Третье - контродировать сроки реализации и иметь аргументы для дискуссии с спонсорами и продуктами
Заниматься постановкой задач команде - да, если реально компания маленькая. Но в таких часто тим лид/архитектор таким занимаются.
Инцедент менеджмент - тут конечно весело. По хорошему, часть этой задачи должна быть унифицирована и централизована в рамках организации, так как это намного дешевле и эффективнее. Плюс все команды будут выравняны по критериям качества и прочему. Читать логи - это уже полный треш. Логи читают разрабы. Они их пишут. Если ему не ясно по логам - тикет на лоб по детализации логов и пендаль :)
На больших курсах - нет. Максимум конкретные тренинги до 5 дней, на конкретную технологию или скилл. Такого было до фига и с горкой
Бвли ли они полезны? Конечно. Они концентрированные, и обычно тебе либо дается хороший толчок, либо систематизация накопленной практики
Более длительные не имеют смысла для компании. Это значит, что изначально взят не тот человек, которого надо просто "вернуть в школу". Т.е. ему надо внести в голову какие-то азы и для этого надо больше времени
Странная рекомендация. Начну с начала. Зачем собеседуем?
Мы пытаемся понять, подходит ли кандидат в команду. Кандидат пытается понять, надо ему или нет. Если сосредоточится на первой части, то логично прийти на собеседование со списоком вопросов, которые должны обеспечить получение информации о кандидате и сравнить его с другими.
И тут очевидно торчат ушки некоторой систематизации вопросов, их категоризации. И применения простого и всегда работающего принципа "в хорошем вопросе половина правильного ответа". На собеседовании еще проще, так как мы ж не задаем вопрос про неизвестное нам. Мы знаем, если ты тимлид, что должно быть в ответе.
Все. Зная ответы, строим вопросы так, чтобы либо их получить, либо получить четкий сигнал, что кандидат этого не знает.
Как именно? Предполагается, что тим лид уже умеет говорить с людьми, и в состоянии лидить разговор, чтобы прийти тому, что ему надо.
А в статье ... зачем придумали http? Кому это было надо? Спроси меня такое, я подумаю, что с той стороны сидит идиот 60+, которому реально хочется получить буквальные ответы на эти вопросы и поговорить о временах, когда трава была зеленее и дальше по списку
Если о самом языке - то это формализованная штука. Очень. Советую написать что-то типа семантического разбора математического выражения, сразу придет понимае :)
С точки зрения сути - язык программирования, это способ изложить свои мысли в рамках определнной парадигмы программирования :) Т.е. это не живой язык, а то, что связано с мвшлением определнным образом, например объекто-ориентированное.
Т.е. мышление первично, а язык связан с ним. Это что-то похоже на связь мышления и языка в философии. Но мышление первично.
А где гуманитарий и объекто-ориенировавнное программирование надеюсь пояснять не надо?
Сложная ситуация. Честно говоря, аналитики все разные и на собеседовании сложно выявить
Да, легко проверить технические знания, ем более часто там проверять особо нечего.
Можно попросить нарисовать схему процесса, но ценным является не ее срисовка, а умение понять потребность заказчика и нарисовать то, чего нег, но будет работать
Можно попросить рассказать, как контролировать полноту требований, скоуп, но на реальном проекте вылезет, что аналитик не понимает проект и этого не может сделать в принципе
Самое важное:
Землеройка, аналитик не пишет кол, он склеивает заказчика и разработку и его обязанности часто формально недоопределены. Поэтому копать до побеы - обязательное условие
Коммуникабельность и умение работать с конфликтами. Птица говорун по сути бесполезна. Важно уметь слушать всех, запоминать и сводить в одну точку. И эту точку описать максимально прозрачно для всех. Но если не можешь - не все потеряно, можно работать на вторых ролях, если на проекте больше одного
Ориентированность на результат. Это основное, код, строиз, 100500 выполненных задач - по фиг, если продукт не работает так как надо. Надо понимать цель и под нее строить все, в том числе заказчик, который первый готов уйти убсуждать шрифты или цыювет фона. Все меряется продуктом - вышло хреново, аналитика на кол, как минимум главного. Не понимая цели, можно получить 100500 тасок, которые не собиратся в целое
Готовность слушать всех и прочить помощь зала. Аналиьик часто самый слабый спец во всем. Технически он слабее любрго дева, в бизнесе все равно шaрит меньше чем SME, в дизайне ... и так во всем. Агалиьик не должен брать на себя, он должен собиоать все мнения и помогать выйти на решение
КАк проверить? Не знаю. По рекомендации. Это более менее раьотает
Остальное - честно, ты либо попадешь в проблему, либо узнаешь потом.
В целом в статбе все неплохо, но из опыта есть куча примеров, что у коассного на вид спеца был скелет в шкафк, который его помножил на ноль
Корона на голове
Спорщик
Безинициативная все уточняющая овечка
Небрежность
Хитросделанная редиска, которая имеет огромный опыт эмуляции работы
На последних собеседованиях тим лид просил рассказать о преймуществах микросервисом перед монолитом. Мне же (я больше выполнял функцию постороннего оценщика) после каждого ответа собеседуемого было интересно привести пример, что приведенное в пример преймущество достижимо и в монолитной архитектуре и послушать ответ,из которого понять, человек реально думает или просто заучил
Но интересно другое ... в реале разницы особо нет :) Точнее есть, но скорее не на уровне могу/не могу, а ближе к дискуссии уровня левый руль/правый руль
Как минимум, для обычных бизнес задач
С другой стороны, ценнсть того, что в данный момент все в команде шагают в ногу реально важна, путь даже и ритм просто один из
Мне кажется, суть статьи во фразе "И все они, как и я, испытывают очень серьезные затруднения при поиске новой работы."
Т.е. статья написана человеком, который имеет сложности с поиском работы и вращается в круге таких же. Это в целом достаточно :)
По собеседования ... по опыту, если ищешь человека на не очень большую ставку, отсев очень большой. Реально, можно играть в игру "я закончу собеседование за 10 минут ... а я за 9 ... ок, собеседуй". Многие кандидаты просто не знают элемкнтарных вещей, вообще. И так было и раньше. Помню в 2000е искали кандидатов, где главный технический критерий был знание SQL. Было 4 запроса, от простого к сложному. Сложный был что-то вроде выбрать сначала с чем-то самым большим, а потом с ними еще что-то сделать. Ничего заумного, реально. До 4го не доходил почти никто, да и до третьего тоже
По своему негативному опыту. Было собеседование (архитектор), когда спрашивали кучу терминов, которых я не знал. Я их и сейчас наверное не знаю, но им было очень важно.
Было неуспешное, когда искали спеца на нишевые задачи в базах и реально спрашивали нюансы, на фоне которых щнание сайд эффекта от ключа, не подпертого индексом кажутся цветочками. Наверное и хорошо
Хорошие србеседования, когда с той стороны сидит умный человек и вы просто беседуете. Есть о чем, можно обменяться мыслями и в конце прийти к соглашению о потенутале возможного сотрудничества. Жаль, трудно понять, насколько ты являешьс таким человнком, когда собеседуешь :)
Не знаю, по итогу и о чем. Я бы скпзал, сто либо автор не склонен все струтктурировать, либо у него было настроение просто писать как пишется. И потом сразу опубликовать :)
Про козлов да, но к сожалению они маскируются. Но точно надо их увольнять
Из своего опыта, лениво счиьпть, но наверное кандидатов 50 было самвх разных должнлстей. Я под позицию выделяю 5-6 основных скиллов/умений/качеств и под них пишу вопросы
После собеседования ставлю оценки, потом кандидаты сравниваются. Легко сказать, что этот тут лучше или хуже и видится картина
Как минимум я пвтаюсь понять, почему этот учше того
Мне кажется статья очень поверхностно описывает суть явления "рок-звезды" в ИТ организации. С позиции не организации, где эта "звезда" может оказаться одним из 10000 записей в зарплатной ведомости, именно этого человека в роли эсперта.
Даже в такой отрасли, как командный спорт, потеря звезды может не являться проблемой для результатов команды и организации. Есть куча примеров, когда потеря звезды пошла на пользу, равно как и обратных. Есть примеры достижения спротивного успеха вообще без звезд (но редко, а часто на коротких турнирах). Но там звезды нужны, и работа с ними, в том числе расставание является частью процессов управления командой. Но даже в таком, казалось бы ориентированном на звезд бизнесе, звездой может оказаться тренер (интересно, кого-то смушает, что он уже не может бить по мячу?) или даже менеджер (что правда почти не интересно фанатам). Но если копнуть еще чуть-чуть, то окажется, что успешность клубов определяется не столько спортивными достижениями, а прибылью. Спортсмены вообще тотальные лузерв, если мерять не отдельными матчами, а турнирами. Победитель один, остальные проиграли и статистика очень сильно против каждого :)
Но вот быть прибыльным многие годы, наращивать фпнатскую базу и спонсорские контракты - эта невидимая и основная часть работы клуба. И она определяет общий его потенциал, так как в конечном итоге система превратит количество в качественный, пусть даже и единичный результат.
Тоже самое в ИТ. Только хуже. Разработка такая же маленькая, не, намного меньшая часть общих процессов компании. И локальная звездочка этого процесса - реально очень малая величина на фоне всего неба :)
Про остальное - тейлоризация: вы попробуйте реализовать на практике :)
Особенно в живом проекте. Ну факты типа спецификации входящего сообщения - можно, но и в коде можно посмотреть. Описание логики работы метода - сомнительно. Описание почему сделали так - вообще никогда. А это самое важное, так как все "грабли" тут
Я чуток знаю ;) Но - это не гуманитарная наука
Это скилл сет, который требуется на позицию. Люди не роботы, и почти всем, кто видиь других людей и как-то общаеься с ними, нужны soft skills. Но это никак не делает архитектора психологом или, ну не знаю, лингвистом. Ну бред. Я говорю/пишу, просто в жизни? Я гуманитарий, потому что использую язык?
Я написал email. Бинго, я гуманитарий, я перенес мои мысли на "бумагу" а другой человек прочитал. Ну маразм же :)
Если я прочитал чужой код - ну я точно гуманитарий так как смог по наскальным письменная предшественника пофиксить его баг
Это навыки коммунакации, котррые человек использует задолго до того, как это стало "наукой" (в глазах некоторых).
К примеру, я делаю презентацию. Я часто это делаю. Я гуманитарий? Чо, правда?
Ну честно, много воды ни о чем :)
Сорри, но либо давая по сути, к примеру берем язык и на примере конкретной задачи ищем гуманитарные корни, либо не натягиваем сову на глобус
Принимая во внимание популярную оценку стоимости решения, которая говорит, что прибавление одной 9ки приводит к добавлению одного 0 к сумме контракта, хочется заметить, что рекомендации как и чего построить без знания бюджета выглядят не очень корректно
Я такого не считаю
Я просто не вижу гуманитарной составляюшей
Давай проще - ты видишь, укажи конкретно :) Слова язык недостаточно, так как это разные семантические смыслы
Мне кажется, анкеты и прочее ... этим никто не занимается
Есть полезное упражнение. Ретроспектива. Оно есть в методичках по скраму и т.д. Его можно применять к себе для анализа что и как.
Для адекватного применения:
Надо пытаться слушать, что происходит вокруг и тогда можно узнать, что что-то идет не так
Надо искать причину в себе и пытаться понять, а что я мог слелать, чтобы вышло лучше
Но это никак не связано с описанным эффектом. Он просто констатирует статистически определенные паттерны поведения. Ну и тихонько так говорит "сомневайся и проверяй себя" )
Обычно и на одну компетенуию сложно найти человека, а тут на 5 условно :)
Скорее вы не зрелая компания, и это не обязательно плохо. Скорее хорошо, так как вы растете и вам нужны сейчас "единороги"
Теперь по ролям.
ПМ: по хорошему, этот человек отвечает за бюджет и сроки, а также за то, что результат работы соответствует ожиданиям заказчика/продакта. Да, у него есть много обязанностей и они перечисленны неплохо. Скрам-мастер - я лично считаю, что отдельный человек - это блажь, и возложение этой роли на ПМ - это хорошо. Но по большому счету, так и раньше было, просто многим захотелось попилить денег на консалтинге вокруг модных тогда слов и технологий
Аналитик - странно. Да, бывают ПМ, которые колупаются в требованиях больше необходимого. Это либо от безделья, так как проект и команда небольшие, либо потому что это бывший аналитик, которому забыли напомнить, что он уже не аналитик. ПМ должен в требованиях понимать взаимосвязь, критичность и цену реализации. Первое позволяет планировать и проверять, что все загружены и на ближайший спринт все логично. Второе - выстраивать приоритеты и делать более ценное раньше. Третье - контродировать сроки реализации и иметь аргументы для дискуссии с спонсорами и продуктами
Заниматься постановкой задач команде - да, если реально компания маленькая. Но в таких часто тим лид/архитектор таким занимаются.
Инцедент менеджмент - тут конечно весело. По хорошему, часть этой задачи должна быть унифицирована и централизована в рамках организации, так как это намного дешевле и эффективнее. Плюс все команды будут выравняны по критериям качества и прочему. Читать логи - это уже полный треш. Логи читают разрабы. Они их пишут. Если ему не ясно по логам - тикет на лоб по детализации логов и пендаль :)
На больших курсах - нет. Максимум конкретные тренинги до 5 дней, на конкретную технологию или скилл. Такого было до фига и с горкой
Бвли ли они полезны? Конечно. Они концентрированные, и обычно тебе либо дается хороший толчок, либо систематизация накопленной практики
Более длительные не имеют смысла для компании. Это значит, что изначально взят не тот человек, которого надо просто "вернуть в школу". Т.е. ему надо внести в голову какие-то азы и для этого надо больше времени
Странная рекомендация. Начну с начала. Зачем собеседуем?
Мы пытаемся понять, подходит ли кандидат в команду. Кандидат пытается понять, надо ему или нет. Если сосредоточится на первой части, то логично прийти на собеседование со списоком вопросов, которые должны обеспечить получение информации о кандидате и сравнить его с другими.
И тут очевидно торчат ушки некоторой систематизации вопросов, их категоризации. И применения простого и всегда работающего принципа "в хорошем вопросе половина правильного ответа". На собеседовании еще проще, так как мы ж не задаем вопрос про неизвестное нам. Мы знаем, если ты тимлид, что должно быть в ответе.
Все. Зная ответы, строим вопросы так, чтобы либо их получить, либо получить четкий сигнал, что кандидат этого не знает.
Как именно? Предполагается, что тим лид уже умеет говорить с людьми, и в состоянии лидить разговор, чтобы прийти тому, что ему надо.
А в статье ... зачем придумали http? Кому это было надо? Спроси меня такое, я подумаю, что с той стороны сидит идиот 60+, которому реально хочется получить буквальные ответы на эти вопросы и поговорить о временах, когда трава была зеленее и дальше по списку
Статья о том, что мы потратили много денег и довели до конца то, что нам посоветовали "крутые" консалтере
Даже не так, это доклад для конференции, где собрались большие дядьки за много денег, и мы решили рассказать, как мы потратили много денег.
Так это всегда так
Тоже самое с курсами по всяким методологиям и т.д.
Заработок точно у тех, кто ведет курсы :)
Человек кодом не говорит
А записывает результаты мыслительного процесса в определенной парадигме
Если она тебе не известна - ничего не поймешь
И да, слово "язык" многозначно :)
Язык программирования ...
Если о самом языке - то это формализованная штука. Очень. Советую написать что-то типа семантического разбора математического выражения, сразу придет понимае :)
С точки зрения сути - язык программирования, это способ изложить свои мысли в рамках определнной парадигмы программирования :) Т.е. это не живой язык, а то, что связано с мвшлением определнным образом, например объекто-ориентированное.
Т.е. мышление первично, а язык связан с ним. Это что-то похоже на связь мышления и языка в философии. Но мышление первично.
А где гуманитарий и объекто-ориенировавнное программирование надеюсь пояснять не надо?
Интересно, на чем это мнение основано? :)
Сложная ситуация. Честно говоря, аналитики все разные и на собеседовании сложно выявить
Да, легко проверить технические знания, ем более часто там проверять особо нечего.
Можно попросить нарисовать схему процесса, но ценным является не ее срисовка, а умение понять потребность заказчика и нарисовать то, чего нег, но будет работать
Можно попросить рассказать, как контролировать полноту требований, скоуп, но на реальном проекте вылезет, что аналитик не понимает проект и этого не может сделать в принципе
Самое важное:
Землеройка, аналитик не пишет кол, он склеивает заказчика и разработку и его обязанности часто формально недоопределены. Поэтому копать до побеы - обязательное условие
Коммуникабельность и умение работать с конфликтами. Птица говорун по сути бесполезна. Важно уметь слушать всех, запоминать и сводить в одну точку. И эту точку описать максимально прозрачно для всех. Но если не можешь - не все потеряно, можно работать на вторых ролях, если на проекте больше одного
Ориентированность на результат. Это основное, код, строиз, 100500 выполненных задач - по фиг, если продукт не работает так как надо. Надо понимать цель и под нее строить все, в том числе заказчик, который первый готов уйти убсуждать шрифты или цыювет фона. Все меряется продуктом - вышло хреново, аналитика на кол, как минимум главного. Не понимая цели, можно получить 100500 тасок, которые не собиратся в целое
Готовность слушать всех и прочить помощь зала. Аналиьик часто самый слабый спец во всем. Технически он слабее любрго дева, в бизнесе все равно шaрит меньше чем SME, в дизайне ... и так во всем. Агалиьик не должен брать на себя, он должен собиоать все мнения и помогать выйти на решение
КАк проверить? Не знаю. По рекомендации. Это более менее раьотает
Остальное - честно, ты либо попадешь в проблему, либо узнаешь потом.
В целом в статбе все неплохо, но из опыта есть куча примеров, что у коассного на вид спеца был скелет в шкафк, который его помножил на ноль
Корона на голове
Спорщик
Безинициативная все уточняющая овечка
Небрежность
Хитросделанная редиска, которая имеет огромный опыт эмуляции работы
Соглашусь
На последних собеседованиях тим лид просил рассказать о преймуществах микросервисом перед монолитом. Мне же (я больше выполнял функцию постороннего оценщика) после каждого ответа собеседуемого было интересно привести пример, что приведенное в пример преймущество достижимо и в монолитной архитектуре и послушать ответ,из которого понять, человек реально думает или просто заучил
Но интересно другое ... в реале разницы особо нет :) Точнее есть, но скорее не на уровне могу/не могу, а ближе к дискуссии уровня левый руль/правый руль
Как минимум, для обычных бизнес задач
С другой стороны, ценнсть того, что в данный момент все в команде шагают в ногу реально важна, путь даже и ритм просто один из
Мне кажется, суть статьи во фразе "И все они, как и я, испытывают очень серьезные затруднения при поиске новой работы."
Т.е. статья написана человеком, который имеет сложности с поиском работы и вращается в круге таких же. Это в целом достаточно :)
По собеседования ... по опыту, если ищешь человека на не очень большую ставку, отсев очень большой. Реально, можно играть в игру "я закончу собеседование за 10 минут ... а я за 9 ... ок, собеседуй". Многие кандидаты просто не знают элемкнтарных вещей, вообще. И так было и раньше. Помню в 2000е искали кандидатов, где главный технический критерий был знание SQL. Было 4 запроса, от простого к сложному. Сложный был что-то вроде выбрать сначала с чем-то самым большим, а потом с ними еще что-то сделать. Ничего заумного, реально. До 4го не доходил почти никто, да и до третьего тоже
По своему негативному опыту. Было собеседование (архитектор), когда спрашивали кучу терминов, которых я не знал. Я их и сейчас наверное не знаю, но им было очень важно.
Было неуспешное, когда искали спеца на нишевые задачи в базах и реально спрашивали нюансы, на фоне которых щнание сайд эффекта от ключа, не подпертого индексом кажутся цветочками. Наверное и хорошо
Хорошие србеседования, когда с той стороны сидит умный человек и вы просто беседуете. Есть о чем, можно обменяться мыслями и в конце прийти к соглашению о потенутале возможного сотрудничества. Жаль, трудно понять, насколько ты являешьс таким человнком, когда собеседуешь :)
Не знаю, по итогу и о чем. Я бы скпзал, сто либо автор не склонен все струтктурировать, либо у него было настроение просто писать как пишется. И потом сразу опубликовать :)
Про козлов да, но к сожалению они маскируются. Но точно надо их увольнять
Из своего опыта, лениво счиьпть, но наверное кандидатов 50 было самвх разных должнлстей. Я под позицию выделяю 5-6 основных скиллов/умений/качеств и под них пишу вопросы
После собеседования ставлю оценки, потом кандидаты сравниваются. Легко сказать, что этот тут лучше или хуже и видится картина
Как минимум я пвтаюсь понять, почему этот учше того
Чего-то люто до фига. Стоит порыться в себе :)
Мне кажется статья очень поверхностно описывает суть явления "рок-звезды" в ИТ организации. С позиции не организации, где эта "звезда" может оказаться одним из 10000 записей в зарплатной ведомости, именно этого человека в роли эсперта.
Даже в такой отрасли, как командный спорт, потеря звезды может не являться проблемой для результатов команды и организации. Есть куча примеров, когда потеря звезды пошла на пользу, равно как и обратных. Есть примеры достижения спротивного успеха вообще без звезд (но редко, а часто на коротких турнирах). Но там звезды нужны, и работа с ними, в том числе расставание является частью процессов управления командой. Но даже в таком, казалось бы ориентированном на звезд бизнесе, звездой может оказаться тренер (интересно, кого-то смушает, что он уже не может бить по мячу?) или даже менеджер (что правда почти не интересно фанатам). Но если копнуть еще чуть-чуть, то окажется, что успешность клубов определяется не столько спортивными достижениями, а прибылью. Спортсмены вообще тотальные лузерв, если мерять не отдельными матчами, а турнирами. Победитель один, остальные проиграли и статистика очень сильно против каждого :)
Но вот быть прибыльным многие годы, наращивать фпнатскую базу и спонсорские контракты - эта невидимая и основная часть работы клуба. И она определяет общий его потенциал, так как в конечном итоге система превратит количество в качественный, пусть даже и единичный результат.
Тоже самое в ИТ. Только хуже. Разработка такая же маленькая, не, намного меньшая часть общих процессов компании. И локальная звездочка этого процесса - реально очень малая величина на фоне всего неба :)
Про остальное - тейлоризация: вы попробуйте реализовать на практике :)
Документация ... удачи в чтении :)
Особенно в живом проекте. Ну факты типа спецификации входящего сообщения - можно, но и в коде можно посмотреть. Описание логики работы метода - сомнительно. Описание почему сделали так - вообще никогда. А это самое важное, так как все "грабли" тут