Чтобы немного развеяться перед выходными, предлагаю подумать над такой задачей. Не смотря на то, что задача сформулирована в шутливой форме, она достаточно реальна.
Представьте себя на месте руководителя проекта, у которого пропал архитектор. В один прекрасный день он просто не вышел на работу и куда-то исчез. Куда он исчез — совершенно не важно: уехал в штаты или принял ислам и стал последователем Талибана — это к делу не относится. Архитектора просто нет. А проект нужно скоро сдавать. Предположим, до сдачи проекта остался месяц.
Нужно сказать, что в текущем виде проект не устраивает ни инвесторов, ни пользователей. Он глючит, многие вещи отдает на откуп самим пользователям, хотя программа могла бы выполнять их сама. В общем, вам позарез нужен архитектор. Проект, что называется, "горит".
Внимание, вопрос: Как Вы будет проводить собеседования с кандидатами на роль архитектора? Какие задания будете им предлагать? На что будете обращать внимание? Что для вас важно, а что не важно?
Конечно, как и у всякой задачи, у этой есть свои ограничения: задания (да и всё собеседование) не должны отнимать ни у кандидата, ни у вас много времени. Во всяком случае, вы не планируете потратить на разговор больше 2-х часов.
Здравствуйте, Mystic, Вы писали:
M>Взять самого толкового программера в команде и повысить до почетного звания "архитектор". Задача свелась к приему на работу обычного программиста.
ИМХО, это разумно. Но все-таки задача была про собеседование. Предположим, Вы решили взять человека со стороны...
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Итак, какие будут предложения?
повысить когото из оставшейся команды.
брать человека со стороны на такой короткий срок не имеет смысла.
обычный девелопер то начинает приносить пользу хорошо если через неделю.
В случае если всеже надо нанять человека со стороны, я бы смотрел только на предыдущий опыт.
какие проэкты, на сколько близки по доменной области и т.д.
... << RSDN@Home 1.2.0 alpha 4 rev. 1227>>
Re[2]: Пятничная задача: собеседование архитектора
Здравствуйте, cvetkov, Вы писали:
C>брать человека со стороны на такой короткий срок не имеет смысла. C>обычный девелопер то начинает приносить пользу хорошо если через неделю.
Уточню некоторые ограничения:
1) Принято стратегическое решение — брать человека со стороны. Почему? Допустим, есть сомнения в достаточной квалификации команды. Т.е. писать код — могут, а вырабатывать архитектурные решения — нет. Поэтому и нужен спец со стороны, который решит проблему и заодно обучит команду.
2) По срокам возможна подвижка. Инвестору важен качественный продукт.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ> до сдачи проекта остался месяц.
Я бы сказал, что пить боржоми поздновато.
КЛ>в текущем виде проект не устраивает ни инвесторов, ни пользователей. Он глючит, многие вещи отдает на откуп самим пользователям, хотя программа могла бы выполнять их сама. КЛ>В общем, вам позарез нужен архитектор.
Проекту позарез нужен новый менеджер, который все это разрулит.
Re[2]: Пятничная задача: собеседование архитектора
Здравствуйте, ZevS, Вы писали:
ZS>Проекту позарез нужен новый менеджер, который все это разрулит.
Предположим, новый менеджер появился. Искать-то архитектора всё равно надо. Какие будут к нему вопросы?
Здравствуйте, Sshur, Вы писали:
S>Лучший способ собеседования ИМХО — попросить рассказать о предыдущем проекте, с уточняющими вопросами как было сделано то-то и то-то.
Предположим, человек рассказывает Вам о предыдущем опыте. Какая информация для Вас будет критичной? По каким критериям Вы будете оценивать кандидата и принимать решение?
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Итак, какие будут предложения?
Горящему проекту, который должен быть сдан через месяц архитектор уже нафик не нужен.
На данном этапе основная задача ложится на плечи менеджера проекта:
он должен представить провал успехом и раскрутить заказчика на новый контракт на поддержку и развитие системы.
Завидую людям, которые могут себе позволить никуда не спешить.
Re[3]: Пятничная задача: собеседование архитектора
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, Sshur, Вы писали:
S>>Лучший способ собеседования ИМХО — попросить рассказать о предыдущем проекте, с уточняющими вопросами как было сделано то-то и то-то. КЛ>Предположим, человек рассказывает Вам о предыдущем опыте. Какая информация для Вас будет критичной? По каким критериям Вы будете оценивать кандидата и принимать решение?
По субъективным критериям Видно же, когда человек понимает, что говорит, а когда не понимает. Пусть в резюме у него будет написано "участвовал в разработке такой-то системы" и формально он имеет необходимый опыт. Однако на деле участие может быть разным — от "подай-принеси-не мешайся" до разработки концептуальных вещей. Главные вопросы — чтобы мог внятно сказать, как что-то сделано, и зачем сделано именно так
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
Re[3]: Пятничная задача: собеседование архитектора
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, ZevS, Вы писали:
ZS>>Проекту позарез нужен новый менеджер, который все это разрулит. КЛ>Предположим, новый менеджер появился. Искать-то архитектора всё равно надо. Какие будут к нему вопросы?
Ваша фамилия Фунт?
Re[4]: Пятничная задача: собеседование архитектора
Здравствуйте, ZevS, Вы писали:
ZS>Ваша фамилия Фунт?
Это вопрос кандидату, если что. )
Ну а если более-менее серьезно — рассказать в подробностях, что за проект и какие задачи стоят, и попросить озвучить примерные шаги. Ну и про опыт решения подобных задачь тоже поспрашивать.
Re[3]: Пятничная задача: собеседование архитектора
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, Mystic, Вы писали:
КЛ>Предположим, Вы решили взять человека со стороны...
Маловероятный сценарий. Основные риски: (1) у архитектора большой срок вхождения в проект, ведь ему надо будет разобраться во всем; (2) разрабатывать проекты можно по разному. Есть вероятность того, что архитектор будет на совместим с командой.
Ну а так надо смотреть на цели. Если это развитие, то я бы более расспросил о предыдущих проектах. Тут приоритет отдавался бы людям, которые работали примерно в такой же ситуации, что есть у нас сейчас на проекте. Также, задавал всякие вопросы, типа "скажите ваше мнение о goto", и бонус бы выдавал людям, которые бы давали более гибкие ответы, без догматизма.
Если речь идет о большом рефакторинге, то тогда брал бы архитектора того, кто бы имел наибольший опыт/знания в той модели разработки, куда мы собираемся двигаться. В этом случае также необходимо предоставить архитектору возможность управления командой: кого-то уволить, кого-то нанять со стороны. И нужно время на перестройку.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Представьте себя на месте руководителя проекта, у которого пропал архитектор. В один прекрасный день он просто не вышел на работу и куда-то исчез. Куда он исчез — совершенно не важно: уехал в штаты или принял ислам и стал последователем Талибана — это к делу не относится. Архитектора просто нет. А проект нужно скоро сдавать. Предположим, до сдачи проекта остался месяц.
Так бывает, когда проект гнил довольно долго. раз он гнил при участии архитектора, с какой стати за есяц при новом архитекторе все станет хорошо ?
Уже поздно обращаться за помощью к архитектору.
КЛ>Нужно сказать, что в текущем виде проект не устраивает ни инвесторов, ни пользователей. Он глючит, многие вещи отдает на откуп самим пользователям, хотя программа могла бы выполнять их сама. В общем, вам позарез нужен архитектор. Проект, что называется, "горит".
Обрезать функционал и зерелизить что есть или попробовать сместить сроки.
КЛ>Внимание, вопрос: Как Вы будет проводить собеседования с кандидатами на роль архитектора? Какие задания будете им предлагать? На что будете обращать внимание? Что для вас важно, а что не важно?
Да никак. Собеседования отнимают вагон времени, а его и так нет.
КЛ>Конечно, как и у всякой задачи, у этой есть свои ограничения: задания (да и всё собеседование) не должны отнимать ни у кандидата, ни у вас много времени. Во всяком случае, вы не планируете потратить на разговор больше 2-х часов.
Идеальный конечный результат — объявление вывесить, на собеседования приглашать после релиза.
P.S. Я когда то наблюдал довольно долго за проектом, накотором архитектор фиксил баги сменой архитектуры за две недели — месяц до релиза.
Материал из Википедии — свободной энциклопедии, -_*
Re[3]: Пятничная задача: собеседование архитектора
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Уточню некоторые ограничения:
КЛ>1) Принято стратегическое решение — брать человека со стороны. Почему? Допустим, есть сомнения в достаточной квалификации команды. Т.е. писать код — могут, а вырабатывать архитектурные решения — нет. Поэтому и нужен спец со стороны, который решит проблему и заодно обучит команду.
Это за месяц то ?
КЛ>2) По срокам возможна подвижка. Инвестору важен качественный продукт.
Какая подвижка, сколько проект писался ?
Материал из Википедии — свободной энциклопедии, -_*
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Представьте себя на месте руководителя проекта, у которого пропал архитектор. КЛ>Предположим, до сдачи проекта остался месяц. КЛ>Нужно сказать, что в текущем виде проект не устраивает ни инвесторов, ни пользователей.
КЛ>Итак, какие будут предложения?
В последний месяц архитектор не нужен — самый завалящий тестер будет полезнее в сто раз.
Я бы предложил менеджеру выполнить сэппуку публично перед инвесторами. Ибо описанная ситуация — чуть менее чем полностью его личная вина. Если сумма затраченная на проект не слишком велика, то можно ограничится отрубанием фаланги пальца.
Re[2]: Пятничная задача: собеседование архитектора
В сообщении задача уточнена. Ключевая задача — наим нового архитектора на рефакторинг. Сроки проекта можно подвинуть. Какие вопросы будете задавать? По каким критериям принимать решение?
Здравствуйте, mazurkin, Вы писали:
M>Я бы предложил менеджеру выполнить сэппуку публично перед инвесторами. Ибо описанная ситуация — чуть менее чем полностью его личная вина. Если сумма затраченная на проект не слишком велика, то можно ограничится отрубанием фаланги пальца.
Здравствуйте, _Dinosaur, Вы писали:
_D>Горящему проекту, который должен быть сдан через месяц архитектор уже нафик не нужен. _D>На данном этапе основная задача ложится на плечи менеджера проекта: _D>он должен представить провал успехом и раскрутить заказчика на новый контракт на поддержку и развитие системы. _D>
сообщении задача уточнена. Ключевая задача — наим нового архитектора на рефакторинг. Сроки проекта можно подвинуть. Какие вопросы будете задавать? По каким критериям принимать решение?
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, -_*, Вы писали:
КЛ>В сообщении задача уточнена. Ключевая задача — наим нового архитектора на рефакторинг. Сроки проекта можно подвинуть. Какие вопросы будете задавать? По каким критериям принимать решение?
Ну, во-первых, скорее всего никакой архитектор не нужен. Разумный рефакторинг может сделать разумный разработчик (возможно — действительно со стороны).
Выделенный архитектор нужен при размере проектов от десятков человеколет, на меньших вполне достаточно тимлида (выполняющего и обязанности архитектора) или сеньора.
Во-вторых, оценить архитектора может (по хорошему) только другой архитектор. Ищешь кого-то, кому доверяешь и просишь провести собеседование. Денег это стоит не слишком много. Собственно менеджеру нужно оценить коммуникативные способности и соответствие нормам компании.
В-третьих, хороший архитектор на такую задачу не пойдет (так как работа явно временная и не слишком интересная, лучше уж поискать что-нибудь более долговременное и престижное).
Если беда не в отвратительном менеджменте команды (т.е. проблема именно в архитектуре, а не в бардаке среди разработчиков), то проще и полезнее не нанимать архитектора, а просто заказать "консультации". В сумме получится дешевле, а найти архитектора на такой заказ будет проще. Я вот иногда таким занимаюсь, да и не только я.
Re[4]: Пятничная задача: собеседование архитектора
сообщении задача уточнена. Ключевая задача — наим нового архитектора на рефакторинг. Сроки проекта можно подвинуть. Какие вопросы будете задавать? По каким критериям принимать решение?
Ну раз ключевая задача — рефакторинг, то и спрашивать про рефакторинг, метрики кода, паттерны и прочие плюшки.
Только получится что будет программист, а не архитектор
Вообще есть интересный вопрос: какие вообще задачи налагаются на архитектора в данном случае. А то я последнее время встречаю мнение что "архитектор" это не должность, а "звание", которое обозначает что человек спроектировал какую-то систему или был ключевым участником этого проектирования.
Re[3]: Пятничная задача: собеседование архитектора
.
КЛ>Нужно сказать, что в текущем виде проект не устраивает ни инвесторов, ни пользователей. КЛ>Он глючит, многие вещи отдает на откуп самим пользователям, хотя программа могла бы выполнять их сама. КЛ>В общем, вам позарез нужен архитектор.
На мой вгляд, вам для начала нужен А.Купер ("About Face").
Т.е. человек умеющий проектировать пользовательский интерфейс.
Что касается собеседования, то расспросите человека о его опыте работы, о том какие задачи он решал, какие решения им принимались и почему именно они.
Спросите его о подходах к решению какой-либо проблемы, стоявшей/стоящей перед разработчиками в ходе выполнения вашего проекта.
Я думаю, что собеседование не будет длиться более получаса.
Завидую людям, которые могут себе позволить никуда не спешить.
Re[4]: Пятничная задача: собеседование архитектора
сообщении задача уточнена. Ключевая задача — наим нового архитектора на рефакторинг. Сроки проекта можно подвинуть. Какие вопросы будете задавать? По каким критериям принимать решение?
Иходное состояние — проект пришел к загниванию при участии архитектора. Времени мало, на сколько можно подвинуть сроки — не ясно, мб неделя, может быть полгода ?
В твоем случае предполагается рефакторингом исправить систуацию
1. исправить дизайн
2. взяь контроль над качеством
П. 1 — время зависит от того, сколько писался проект. Если проекту год, то за месяц много не нарефакторишь. Для рефакторинга нужно глубокое вхождение в проект. Сколько времени длится проект — не ясно.
П.2 — здесь рефакторинг могу проводить и девелоперы, но дело в том что и здесь рефакторинг не дает быстрых результатов.
Вообще, про рефакторинг.
Плохой дизайн, плохой код — это своего рода кредит или долг. Его придется возвращать. В отличие от обычного долго, который ты берешь и возвращаешь деньгами, технические долги возращаются :
за счет потери времени и/или денег
а. потеря доверия
б. потеря функционала
в. потеря проекта
г. потеря членов команды
д. потеря возможностей
е. потеря перспектив
Самое важное даже не это. Технический долг имеет такую особенность, как сильную неопределенность. Т.е.
1. не известно когда придется вернуть долг
2. не известно как долго придется возвращать долг
3. не известно в какой форме придется возвращать долг
Что такое рефакторинг. Это вобщем то рестукрутуризация и, частично, возврат долга.
Кроме того, перед релизом я снова предлагаю не нанимать никого. Разве что консультанта по некоторым вопросам, что бы девелоперы могли задавать ему чуть не любые вопросы, что бы разгрузить их частично.
В любом случае рефакторинг не даёт быстрых результатов. Быстрые результаты дают только хаки и упрощение/обрезание функционала.
Материал из Википедии — свободной энциклопедии, -_*
Re[4]: Пятничная задача: собеседование архитектора
Здравствуйте, Дельгядо Филипп, Вы писали:
ДФ>Во-вторых, оценить архитектора может (по хорошему) только другой архитектор. Ищешь кого-то, кому доверяешь и просишь провести собеседование. Денег это стоит не слишком много. Собственно менеджеру нужно оценить коммуникативные способности и соответствие нормам компании.
Предположим, такой архитектор, готовый помочь, имеется. Но он из другого отдела, и руководителю о нем известно не так много. Поэтому руководителю хотелось бы, чтобы архитектор сформулировал критерии, по которым он будет отбирать кандидатов. Какие на его месте критерии предложили бы Вы?
-_*>В любом случае рефакторинг не даёт быстрых результатов. Быстрые результаты дают только хаки и упрощение/обрезание функционала.
Это всё понятно. Инвестор согласен на рефакторинг архитектуры. Нужны критерии для подбора архитектора.
Здравствуйте, gandjustas, Вы писали:
G>Ну раз ключевая задача — рефакторинг, то и спрашивать про рефакторинг, метрики кода, паттерны и прочие плюшки.
Предыдущий архитектор, который исчез, тоже красиво говорил про метрики кода, паттерны и рефакторинг. Однако это не спасло проект. Нужны критерии, по которым можно отобрать способного архитектора.
сообщении задача уточнена. Ключевая задача — наим нового архитектора на рефакторинг. Сроки проекта можно подвинуть. Какие вопросы будете задавать? По каким критериям принимать решение?
Формализованный подход — вряд ли прокатит. Здесь нужен человек, который уже наступал на такие грабли и вляпывался в подобное овно. Т.е. не бесшабашный юнец "ща мы всё тут перепишем по-правильному", а адекватный человек с пониманием business value и ограничений по времени и бюджетам. Немаловажно — уметь общаться с менеджментом проекта и обосновывать трудозатраты "на еще одну переделку". В общем, целевая фигура — типа E.Z. (помнишь — проект Большой Ящик).
Re[6]: Пятничная задача: собеседование архитектора
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, gandjustas, Вы писали:
G>>Ну раз ключевая задача — рефакторинг, то и спрашивать про рефакторинг, метрики кода, паттерны и прочие плюшки. КЛ>Предыдущий архитектор, который исчез, тоже красиво говорил про метрики кода, паттерны и рефакторинг. Однако это не спасло проект.
Неудивительно. Я же и говорю — это программист, а не архитектор.
КЛ>Нужны критерии, по которым можно отобрать способного архитектора.
Если бы однозначные критерии существовали, то видимо разговора бы здесь не было.
Роль архитектора как всегда туманна. Предлагаю для начала очертить круг его обязанностей и сформулировать задачи для проекта в проверяемом виде.
Имея такие сведения можно оценить будущего архитектора по опыту исполнения аналогичных обязанностей и решения задач, а также по возможности тестовые задания выдать.
Re[6]: Пятничная задача: собеседование архитектора
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>-_*>В любом случае рефакторинг не даёт быстрых результатов. Быстрые результаты дают только хаки и упрощение/обрезание функционала. КЛ>Это всё понятно. Инвестор согласен на рефакторинг архитектуры. Нужны критерии для подбора архитектора.
КЛ>Спасибо!
Ты хоть на вопросы то отвечай — уравнение с неизвестным количеством неизвестных восторга не вызывает
Сколько времени писался проект ?
Cколько времени может дать инвестор ?
Cколько есть девелоперов ?
Сколько кода ?
Насколько уникальный проект ?
Cколько есть тестеров ?
Поставлен ли процесс ?
Есть ли какие зависимости от других проектов, людей на стороне инвестора ?
И хочется знать кое что бывшего.
Скажем, связан ли уход с состоянием проекта ?
Были ли к нему претензии ?
Т.е. жду ответов в духе (проставь свои ответы)
1 год
полгода
5
1кк строк
круд для могазина
1
нет
интеграция с соседним и долбеж помогальника инвестора
связан
не было
Материал из Википедии — свободной энциклопедии, -_*
Здравствуйте, Stormblast, Вы писали:
КЛ>>Итак, какие будут предложения?
S>Вам нужен полный ИДИОТ, на которого вы спишите все свои неудачи ... думаю Ваш вопрос, который вы здесь задали как раз для него и подойдет ...
Не, вероятно им нужен некто, кого они называют архитектором, но при этом не могут очертить круг обязанностей.
Материал из Википедии — свободной энциклопедии, -_*
Re[5]: Пятничная задача: собеседование архитектора
Здравствуйте, Mr.Delphist, Вы писали:
MD>Формализованный подход — вряд ли прокатит. Здесь нужен человек, который уже наступал на такие грабли и вляпывался в подобное овно. Т.е. не бесшабашный юнец "ща мы всё тут перепишем по-правильному", а адекватный человек с пониманием business value и ограничений по времени и бюджетам. Немаловажно — уметь общаться с менеджментом проекта и обосновывать трудозатраты "на еще одну переделку". В общем, целевая фигура — типа E.Z. (помнишь — проект Большой Ящик).
Отлично. Первые два критерия сформулированы:
Умудренный человек с опытом, за плечами которого несколько десятков проектов.
Умение обосновывать трудозатраты. (Критерий проверяется при помощи конкретного задания — обосновать трудозатраты для проекта.)
Спасибо!
Здравствуйте, Stormblast, Вы писали:
S>Вам нужен полный ИДИОТ, на которого вы спишите все свои неудачи ... думаю Ваш вопрос, который вы здесь задали как раз для него и подойдет ...
Я же написал — ситуация выдумана, но, конечно, имеет некий прототип. Однако не у нас в компании. Единственное, что важно в данном задании — это легко критерии для проверки квалификации архитектора.
Конечно, у меня есть свой подход к решению этой задачи. И его я изложу чуть позже. Но сначала мне хотелось бы почитать, что думают коллеги.
P.S.: И, пожалуйста, давайте уже завяжем с офф-топиком: квалификация менеджера, предыдущего архитектора, бардак в команде — всё это к обсуждаемой задаче не относится. Предположим, руководство все это осознало и решило изменить ситуацию. Нужно найти вменяемого архитектора, на которого не будут "вешать всех собак".
-_*>Ты хоть на вопросы то отвечай — уравнение с неизвестным количеством неизвестных восторга не вызывает
Я уже писал — ситуация выдумана. Реальная задача такова: есть проект, написанный плохо, который хотят отрефакторить. Т.е. изменить и архитектуру и функционал. Подробности по проекту не знаю, т.к. им занимается совсем другая компания. Если Вам нужны подробности, возьмите в качестве примера Ваш какой-нибудь проект. Интересует — что бы Вы стали спрашивать у кандидата? Какие навыки Вы бы стали проверять? Каким образом?
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Предыдущий архитектор, который исчез, тоже красиво говорил про метрики кода, паттерны и рефакторинг. Однако это не спасло проект. Нужны критерии, по которым можно отобрать способного архитектора. КЛ>Спасибо!
Тогда я бы искал по-знакомству. Например у меня есть хорошие знакомые, коллеги, за которых я могу поручиться, о которых я на 99% (на 100% никто не может гарантировать) уверен, что человек не подведет. Вот и спрашивайте по вашим знакомым, ищите толковых и одновременно надежных людей.
Re[3]: Пятничная задача: собеседование архитектора
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>P.S.: И, пожалуйста, давайте уже завяжем с офф-топиком: квалификация менеджера, предыдущего архитектора, бардак в команде — всё это к обсуждаемой задаче не относится. Предположим, руководство все это осознало и решило изменить ситуацию. Нужно найти вменяемого архитектора, на которого не будут "вешать всех собак".
Ну и отлично. Так и давай на собеседовании смоделируем похожую ситуацию и попросим предложить пути выхода из кризиса.
Людей предлагающих нечто близкое к тому, что произошло в реальности отсеиваем сразу, ответы остальных анализируем и выбираем наиболее подходящий.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[8]: Пятничная задача: собеседование архитектора
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>-_*>Ты хоть на вопросы то отвечай — уравнение с неизвестным количеством неизвестных восторга не вызывает КЛ>Я уже писал — ситуация выдумана. Реальная задача такова: есть проект, написанный плохо, который хотят отрефакторить. Т.е. изменить и архитектуру и функционал. Подробности по проекту не знаю, т.к. им занимается совсем другая компания. Если Вам нужны подробности, возьмите в качестве примера Ваш какой-нибудь проект. Интересует — что бы Вы стали спрашивать у кандидата? Какие навыки Вы бы стали проверять? Каким образом?
Ты задал задачу с неизвестным количеством неизвестных.
Ответ зависит от ответов на приведеные мною вопросы.
Если "возьмите в качестве примера Ваш", то ответ был дан — архитектора не надо. Точка.
Материал из Википедии — свободной энциклопедии, -_*
Re[4]: Пятничная задача: собеседование архитектора
Здравствуйте, genre, Вы писали:
G>Ну и отлично. Так и давай на собеседовании смоделируем похожую ситуацию и попросим предложить пути выхода из кризиса. G>Людей предлагающих нечто близкое к тому, что произошло в реальности отсеиваем сразу, ответы остальных анализируем и выбираем наиболее подходящий.
А в чем мулька ?
Материал из Википедии — свободной энциклопедии, -_*
Re[7]: Пятничная задача: собеседование архитектора
Здравствуйте, MozgC, Вы писали:
MC>Тогда я бы искал по-знакомству. Например у меня есть хорошие знакомые, коллеги, за которых я могу поручиться, о которых я на 99% (на 100% никто не может гарантировать) уверен, что человек не подведет. Вот и спрашивайте по вашим знакомым, ищите толковых и одновременно надежных людей.
Это всё понятно, но, к сожалению, не решает задачу. Предположим, все толковые люди заняты — у них контракты на 50 лет. Чтобы не развивать далее тему знакомых, сразу скажу, что знакомые знакомых и знакомые знакомых знакомых — тоже заняты. Нужно нанять человека с улицы.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Коллеги,
КЛ>Чтобы немного развеяться перед выходными, предлагаю подумать над такой задачей. Не смотря на то, что задача сформулирована в шутливой форме, она достаточно реальна.
КЛ>Представьте себя на месте руководителя проекта, у которого пропал архитектор. В один прекрасный день он просто не вышел на работу и куда-то исчез. Куда он исчез — совершенно не важно: уехал в штаты или принял ислам и стал последователем Талибана — это к делу не относится. Архитектора просто нет. А проект нужно скоро сдавать. Предположим, до сдачи проекта остался месяц.
КЛ>Нужно сказать, что в текущем виде проект не устраивает ни инвесторов, ни пользователей. Он глючит, многие вещи отдает на откуп самим пользователям, хотя программа могла бы выполнять их сама. В общем, вам позарез нужен архитектор. Проект, что называется, "горит".
КЛ>Внимание, вопрос: Как Вы будет проводить собеседования с кандидатами на роль архитектора? Какие задания будете им предлагать? На что будете обращать внимание? Что для вас важно, а что не важно?
КЛ>Конечно, как и у всякой задачи, у этой есть свои ограничения: задания (да и всё собеседование) не должны отнимать ни у кандидата, ни у вас много времени. Во всяком случае, вы не планируете потратить на разговор больше 2-х часов.
КЛ>Итак, какие будут предложения?
Кирилл, искренне верю в то, что данная ситуация не вымышлена
если проект на стадии завершения — архитектор вам уже не сильно нужен так как есть команда разработчиков, можете переделку системы поручить им.
Брать Архитектора уже слишком поздно, поэтому никаких собеседований (при условии что проект не система типа 1С с типовой конфигурацией)
Re[8]: Пятничная задача: собеседование архитектора
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Это всё понятно, но, к сожалению, не решает задачу. Предположим, все толковые люди заняты — у них контракты на 50 лет. Чтобы не развивать далее тему знакомых, сразу скажу, что знакомые знакомых и знакомые знакомых знакомых — тоже заняты. Нужно нанять человека с улицы.
КЛ>Как оценить его квалификацию?
Исходя из того, что проект это круд, который пишут чуть не все подряд, ...
Вобщем, ты уже понял
Материал из Википедии — свободной энциклопедии, -_*
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Конечно, как и у всякой задачи, у этой есть свои ограничения: задания (да и всё собеседование) не должны отнимать ни у кандидата, ни у вас много времени. Во всяком случае, вы не планируете потратить на разговор больше 2-х часов.
КЛ>Итак, какие будут предложения?
Ситуация точь-в-точь как у тебя, только не вымышленая, а реальная
Как то мне чел стукнул в аську — помоги, дескать, баг зафиксить.
Спрашиваю, что за баг, ответ — "Ну вот чето крешится."
Спрашиваю, что за проект, где крешится, что менял и тд и тд.
В ответ, прямо как у тебя: "Проект ты не знаешь ! Не пудри мозг ! Помоги зафиксить !!!" И все это по icq.
Реально оказалось, что в проекте:
1 не моем, про который я и не знал
2 был код, взятый у меня
3 переписаный зачем то с нуля
4 который делал то же самое, что делал мой код
5 но хедер остался мой
Решение было достаточно простое — откатить на ту ревизию где был мой код В итоге с тех пор я удаляю всякие хедеры, что бы люди привыкали смотреть в VCS.
Материал из Википедии — свободной энциклопедии, -_*
Re[5]: Пятничная задача: собеседование архитектора
G>>Ну и отлично. Так и давай на собеседовании смоделируем похожую ситуацию и попросим предложить пути выхода из кризиса. G>>Людей предлагающих нечто близкое к тому, что произошло в реальности отсеиваем сразу, ответы остальных анализируем и выбираем наиболее подходящий.
-_*>А в чем мулька ?
в том что мы сразу ставим его в те условия в которых он окажется. и смотрим как он себя в этих условиях себя поведет
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[6]: Пятничная задача: собеседование архитектора
Здравствуйте, genre, Вы писали:
G>>>Ну и отлично. Так и давай на собеседовании смоделируем похожую ситуацию и попросим предложить пути выхода из кризиса. G>>>Людей предлагающих нечто близкое к тому, что произошло в реальности отсеиваем сразу, ответы остальных анализируем и выбираем наиболее подходящий.
G>-_*>А в чем мулька ?
G>в том что мы сразу ставим его в те условия в которых он окажется. и смотрим как он себя в этих условиях себя поведет
Это я понял. Я хочу знать, какой результат ты хочешь получить.
Материал из Википедии — свободной энциклопедии, -_*
Re[8]: Пятничная задача: собеседование архитектора
Здравствуйте, genre, Вы писали:
G>Здравствуйте, -_*, Вы писали:
G>-_*>Это я понял. Я хочу знать, какой результат ты хочешь получить.
G>Ну очевидно я выберу того, кто предложит приглянувшийся мне вариант исправления ситуации.
По каким критериям ты будешь решать, приглянулся или нет ?
Материал из Википедии — свободной энциклопедии, -_*
Re[9]: Пятничная задача: собеседование архитектора
Здравствуйте, cvetkov, Вы писали:
КЛ>>Как оценить его квалификацию?
C>так ответили уже. по предыдущим проектам. C>выпустил предыдущий проект с такой же сложностью подходит.
Ну выпустил, но почему можно ожидать, что он справится с ситуацией в когда сроков — месяц-другой и не ясно, насколько этот готовы, убитый отличается от того, что выпустил кандидат ?
Материал из Википедии — свободной энциклопедии, -_*
Re[3]: Пятничная задача: собеседование архитектора
-_*>Ну выпустил, но почему можно ожидать, что он справится с ситуацией в когда сроков — месяц-другой и не ясно, насколько этот готовы, убитый отличается от того, что выпустил кандидат ?
Про месяц другой речи не идет. мы же говорим о реальных сроках а не о волшебных.
и конечно это необходимое условие, но отнють не достаточное.
... << RSDN@Home 1.2.0 alpha 4 rev. 1227>>
Re[4]: Пятничная задача: собеседование архитектора
Здравствуйте, Stormblast, Вы писали:
S>это не задача — это старческий маразм от безделья ...
Не вижу ничего маразматичного в вопросе о том, как собеседовать архитектора, что спрашивать и на что обратить внимание.
Здравствуйте, Кирилл Лебедев, Вы писали:
S>>это не задача — это старческий маразм от безделья ... КЛ>Не вижу ничего маразматичного в вопросе о том, как собеседовать архитектора, что спрашивать и на что обратить внимание.
Представляю : "Эй, народ, пособеседуйте архитектора, но что за область, технологии, проект и тд и тд и тд, я вам не скажу !!!"
Материал из Википедии — свободной энциклопедии, -_*
Re[11]: Пятничная задача: собеседование архитектора
Здравствуйте, cvetkov, Вы писали:
C>-_*>Ну выпустил, но почему можно ожидать, что он справится с ситуацией в когда сроков — месяц-другой и не ясно, насколько этот готовы, убитый отличается от того, что выпустил кандидат ?
C>Про месяц другой речи не идет. мы же говорим о реальных сроках а не о волшебных.
Угу, реальных. А кто определяет эту реальность ? Архитектор по идее, после того, как вникнет в проект, сможет оценить время на рефакторинг. Т.е. есть неопределенность в наличии.
Стало быть, нужно искать кого то, кто был в такой же ситуации с таким же проектом Как это проверить на собеседовании — не совсем ясно.
Сдаётся, тут нужен не архитектор, а антикризисный менеджер.
Материал из Википедии — свободной энциклопедии, -_*
Re[10]: Пятничная задача: собеседование архитектора
Здравствуйте, genre, Вы писали:
G>>>Ну очевидно я выберу того, кто предложит приглянувшийся мне вариант исправления ситуации.
G>-_*>По каким критериям ты будешь решать, приглянулся или нет ?
G>Я применю метод в народе известный как "экспертная оценка"
Я не знаю такого метода. Поподробнее раскажи.
Материал из Википедии — свободной энциклопедии, -_*
Здравствуйте, -_*, Вы писали:
G>>>>Ну очевидно я выберу того, кто предложит приглянувшийся мне вариант исправления ситуации. G>>-_*>По каким критериям ты будешь решать, приглянулся или нет ? G>>Я применю метод в народе известный как "экспертная оценка"
-_*>Я не знаю такого метода. Поподробнее раскажи.
Это значит, что ты всех выслушиваешь и потом выбираешь того, кто тебе больше понравился.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[3]: Пятничная задача: собеседование архитектора
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, -_*, Вы писали:
КЛ>В сообщении задача уточнена. Ключевая задача — наим нового архитектора на рефакторинг. Сроки проекта можно подвинуть. Какие вопросы будете задавать? По каким критериям принимать решение?
Тогда надо искать хорошего тимлида а не архитектора.
Необходимо:
1. повысить прозрачность системы (архитектура).
2. повысить гибкость системы (архитектура).
3. поставить контроль качества.
4. начать интенсивное обучение команды (управление).
5. Уточнять состав команды (управление).
6. Усилить прозрачность процессов для разработчиков (управление).
и т.п.
Потому что если не выяснить и убрать причину по которой проект завален, проект не починить.
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[12]: Пятничная задача: собеседование архитектора
Здравствуйте, genre, Вы писали:
G>>>Я применю метод в народе известный как "экспертная оценка" G>-_*>Я не знаю такого метода. Поподробнее раскажи.
G>Это значит, что ты всех выслушиваешь и потом выбираешь того, кто тебе больше понравился.
Это тоже самое что и выбрать любого. Без конкретных критериев все сведется к интуитивным ощущениям. далеко не факт, что интуиция у тебя прокачана именно на отбор таких специалистов. кроме того, какие вопросы задавать ?
Материал из Википедии — свободной энциклопедии, -_*
Если конкретно по вопросам то первое что приходит в голову.
1. Предложить разбить на компоненты и связи обределенный функционал , не большой. Например игра шахматы, сервис взаимодействующий с GoogMap для отрисовки карт, и т.п. как можно ближе к прикладной области.
2. В идеале кандидат спец в необходимой предметной области. Без этого и достаточного опыта, никакой хорошей архитектуры не будет. Напимер для сети и асинхронки , обязаны быть специфические знания и умения.
3. Плавно поговорить о критериях как оценить то или иное решение, предложите оценить несколько разных решений. Как минимум он их должен "чувствовать".
4. Если фантазия не работает , предложите решить имеющиеся проблемы.
Плюс общая проверка на адекватность. Должно хватить.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Коллеги,
Вот хоть убей не пойму чем может помочь новый архитектор в конце проекта, когда своя архитектура уже устаканилась, а на переделку времени не осталось.
Но хрен с ним, будем считать ситуацию вымышленой. Чисто разминка для ума.
Нужен архитектор с опытом. И опыт тут важнее знаний.
Опыт нужен вот зачем: чтобы не бросился переписывать чужую систему "как правильно", а сразу смирился с тем, что большую часть системы он даже не изучит (не то что поменяет там что-то).
Я бы советовал "украсть" архитектора/двух с соседнего проекта, предложив ему 2х/3х зарплату на время "жопы" (второго в качестве экспертной помощи. Принимать решения должен один). Человек ведь провереный, а свои деньги он отработает.
Изначально мэнеджеру нужно взять и составить список задач которые кровь из носа нужно сделать к релизу. Вместе с толковым програмером из команды выделить модули в которые требуется вносить большое кол-во изменений (если у вас нет модулей, то и архитектора у вас не было). На модули где правки можно сделать не меняя дазийн (пусть даже говнокод получится) забиваем -- архитектор там не нужен.
Каким-то образом получаем жизайн этих модулей (UML диаграмм, карандашных набросков или еще чего).
Объявление о найме: сразу говорите, что нужен "кризис архитектор" для преодаления "жопы". На срок 1-2 месяца. Зарплата 2х/3х. После успешного преодаления можно остаться на проекте/в конторе на зарплате 1х. И пусть соискатели будут готовы к тому, что на собеседовании их выепут и высущат.
Вот теперь мы готовы к собеседовнию.
Отвлеченные знания вам нах не нужны, поэтому берете дизайн ваших модуей (ну или чуть измененные если там у вас совсем секретно все), набор тербований (тоже можно изменить) и ставите задачу в таком ключе:
есть система (вот), нужно наиболее быстро добавть в нее новые фичи (эту, эту и вот эту). Что можете предложить в качестве решения?
На собеседовании с нашей стороны должен быть архитектор или хороший програмер. В общем эксперт, который сможет сказать дело предлагает кандидат или нет.
Ясно, что чем дальше мы уйдет от реальных дизайна и требований, тем меньше толку от решения, но хоть поймете умеет ли человек думать.
В общем раз времени мало, а сделать нужно много, то это больше к менеджеру вопрос. Даже самый крутой архитектор не сможет помочь, если у менеджера не будет хватать ресурсов для реализации его изменений.
Ну и дополнительного тестера я бы в любом случае взял.
СУВ, Aikin
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[13]: Пятничная задача: собеседование архитектора
-_*>Это тоже самое что и выбрать любого. Без конкретных критериев все сведется к интуитивным ощущениям.
Угу.
-_*>далеко не факт, что интуиция у тебя прокачана именно на отбор таких специалистов. кроме того, какие вопросы задавать ?
Я так думаю, что если ты сам не архитектор, то даже список вопросов не поможет тебе оценить качество собеседуемого, потому что верных ответов на каждый вопрос может быть не один. Тестом даже джуниора не отобрать, а уж архитектора тем более.
Мой же вопрос позволяет при отсутствии знаний о предмете разговора приблизить интуитивный выбор к реальности.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[12]: Пятничная задача: собеседование архитектора
Здравствуйте, genre, Вы писали:
G>Это значит, что ты всех выслушиваешь и потом выбираешь того, кто тебе больше понравился. Экспертная оценка предполагает оценку на основе группового мнения...
Завидую людям, которые могут себе позволить никуда не спешить.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Итак, какие будут предложения?
В данной ситуации не кандидату вопросы задавать нужно, а отвечать на его вопросы. Предоставить ему материалы по проекту: схему БД, структуру модулей, дать на код посмотреть и т.п., объяснить какие именно проблемы в проекте. А дальше отвечать на его вопросы и слушать его предложения.
Если нам не помогут, то мы тоже никого не пощадим.
По-моему тривиальная задача. Кандидату дается напосмотреть текущий код и список того, что нужно с ним сделать. Показывают команду. После чего он либо соглашается селать это, либо нет. Есть вариант, что кандидат солжет, чтобы плучить место либо переоценит свои силы. Для отсечения таких кандидатов необходимо посмореть портфоли согласившихся и позвонить по предыдущим местам работы. Человека с наиболее внушитеьным портфолио и хорошими отзывами нанимаем, и с ысокой стпенью вероятности он все делает. Увы, денег это будет стоить прилично .
Re[6]: Пятничная задача: собеседование архитектора
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, gandjustas, Вы писали:
G>>Ну раз ключевая задача — рефакторинг, то и спрашивать про рефакторинг, метрики кода, паттерны и прочие плюшки. КЛ>Предыдущий архитектор, который исчез, тоже красиво говорил про метрики кода, паттерны и рефакторинг. Однако это не спасло проект. Нужны критерии, по которым можно отобрать способного архитектора.
Мне казалось, это уровень тех.лида, а не архитектора.
Здравствуйте, genre, Вы писали:
G>Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>>P.S.: И, пожалуйста, давайте уже завяжем с офф-топиком: квалификация менеджера, предыдущего архитектора, бардак в команде — всё это к обсуждаемой задаче не относится. Предположим, руководство все это осознало и решило изменить ситуацию. Нужно найти вменяемого архитектора, на которого не будут "вешать всех собак".
G>Ну и отлично. Так и давай на собеседовании смоделируем похожую ситуацию и попросим предложить пути выхода из кризиса. G>Людей предлагающих нечто близкое к тому, что произошло в реальности отсеиваем сразу, ответы остальных анализируем и выбираем наиболее подходящий.
Согласен. Можно также предупредить (в конце?) что ситуация реальная. Возможно, что кандидату самому будет не интересно в такое влезать, или просто почувствует, что опыта не хватит. А может он скажет что-то вроде "Ну ok. Я уже бывал в подобной ситуации, сделал то-то и то-то".
Здравствуйте, Дельгядо Филипп, Вы писали:
ДФ>В-третьих, хороший архитектор на такую задачу не пойдет (так как работа явно временная и не слишком интересная, лучше уж поискать что-нибудь более долговременное и престижное).
Ну почему же? Я бы пошел. И то что это временная работа, да еще и вызов моим способностям этому благоприятствует. Вот оплату бы я поросил бы высокую. Но это на несколько месяцев. Уверен буджет проекта потянет.
За свою карьеру я вытащил 2 проекта из похожей жопы.
Сроки, конечно, были помягче, да и ситуация другая -- нам в котору пришел проект в полурабочем состоянии после других "индусов-аутсорсеров". Ничего, запустили, причесали, люди пользуются. И знаешь, мне было интересно его реанимировать. Вот только после успешной реанимации мне стало откровенно скучно
Вот так вот.
СУВ, Aikin
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[8]: Пятничная задача: собеседование архитектора
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Это всё понятно, но, к сожалению, не решает задачу. Предположим, все толковые люди заняты — у них контракты на 50 лет. Чтобы не развивать далее тему знакомых, сразу скажу, что знакомые знакомых и знакомые знакомых знакомых — тоже заняты. Нужно нанять человека с улицы.
Вам не нужен специалист на 50 лет. Вам нужен человек, который вытянет вас за 1-2 месяца. Уверен, что большинство занятых людей найдут это время. Да и начальство их отпустит. Меня бы отпустило. А не отпустят, то отпуск за свой счет никто не отменял.
СУВ, Aikin
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[6]: Пятничная задача: собеседование архитектора
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Нужны критерии, по которым можно отобрать способного архитектора.
Вам не нужен способный архитектор. Архитектура не создается в авральном порядке. Способному архитектору может понадобиться месяц толко на то чтобы разобраться в пректе. Хотя разобравшись он (еще за один месяц) предложит такое, что решит все проблемы проекта.
Вам нужен реалист, который понимает, что ту архитектуру, что он напишет за эти неделю-две (ее ведь еще реализовать нужно) в будущем придется выкинуть на помойку (в ином случае этого будущего для проекта не наступит).
Критерии? Ну давай попробум (в порядке возрастания практики):
1) Реалист с хорошим опытом за плечами. ИМО, очень важны неуспешные проекты и поднятие из руин чужих проектов. Как известно, победы не учат, в отличии от неудач.
2) Пракитующий кодер. Может не только придумать, но и реализовать свою идею (чем он и будет заниматься большинство времени).
3) Никакого булщита по поводу метрик, качества кода, 100% покрытия тестами и привержености паттернов (за каждое слово произнесенное в этом ключе я бы давал штрафные баллы).
4) Понимает, что менять код нужно только там, где ожидается. Тем более понимает, что архитектурные изменения/правки в дизайне -- самые дорогие.
5) Не ищет "идеального" решения. Может остановится на приемлемом решении, а не продолжать поиски "идеала".
Можно еще что-то написать, но... ты ведь опять скажешь, что это не то
СУВ, Aikin
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[7]: Пятничная задача: собеседование архитектора
Здравствуйте, Aikin, Вы писали:
A>Критерии? Ну давай попробум (в порядке возрастания практики): A>1) Реалист с хорошим опытом за плечами. ИМО, очень важны неуспешные проекты и поднятие из руин чужих проектов. Как известно, победы не учат, в отличии от неудач. A>2) Пракитующий кодер. Может не только придумать, но и реализовать свою идею (чем он и будет заниматься большинство времени). A>3) Никакого булщита по поводу метрик, качества кода, 100% покрытия тестами и привержености паттернов (за каждое слово произнесенное в этом ключе я бы давал штрафные баллы). A>4) Понимает, что менять код нужно только там, где ожидается. Тем более понимает, что архитектурные изменения/правки в дизайне -- самые дорогие. A>5) Не ищет "идеального" решения. Может остановится на приемлемом решении, а не продолжать поиски "идеала".
Эти качества должны быть у любого кто связан с разработкой.
A>Можно еще что-то написать, но... ты ведь опять скажешь, что это не то
Писать что угодно не имеет смысла так как не определены цели.
В таком виде как тут описывается нужен кто-то, кто сделает чудо и вытащит проект из *овна. Будет это ПМ, программист, архитектор или еще кто-то неважно.
Re[8]: Пятничная задача: собеседование архитектора
Здравствуйте, gandjustas, Вы писали:
G>Эти качества должны быть у любого кто связан с разработкой.
Должны, согласен. Но у многих, судя по моему опыту, их нет. Я сам пролечу по нескольким пунктом (если дать мне волю ). А уж я 2-х/3-х летней давности...
A>>Можно еще что-то написать, но... ты ведь опять скажешь, что это не то G>Писать что угодно не имеет смысла так как не определены цели.
Ну как же. А то самое: "себя показать, на других посмотреть"?
СУВ, Aikin
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[4]: Пятничная задача: собеседование архитектора
Здравствуйте, minorlogic, Вы писали:
M>Тогда надо искать хорошего тимлида а не архитектора.
Возможно, действительно нужен хороший тимлидер или тимлидер и архитектор в одном лице. Нередко заказчику (особенно, если он не технарь) трудно сформулировать, кто ему нужен. Но в данной теме мы мне хотелось бы обсудить, как проверять "архитектурные" навыки кандидата.
M>Необходимо:
M>1. повысить прозрачность системы (архитектура). M>2. повысить гибкость системы (архитектура).
Это всё общие слова. Допустим, система обладает определенными недостатками — ряд функций, которые может выполнять сама, отдаёт на откуп пользователю. Эти конкретные недостатки и нужно исправить в следующей версии. А что такое "прозрачность" и "гибкость" — непонятно.
M>Потому что если не выяснить и убрать причину по которой проект завален, проект не починить.
Это всё понятно. Допустим, менеджер всё делает правильно в этом направлении. Нужно просто отобрать вменяемого архитектора — как-то проверить его квалификацию.
Здравствуйте, minorlogic, Вы писали:
M>1. Предложить разбить на компоненты и связи обределенный функционал , не большой. Например игра шахматы, сервис взаимодействующий с GoogMap для отрисовки карт, и т.п. как можно ближе к прикладной области.
Таким образом, один из критериев — архитектор должен уметь выполнять декомпозицию сложной и крупной задачи на легкие и небольшие, сложной системы — на подсистемы и взаимосвязи между ними. Однако этот критерий хорошо, когда ясно, по какому принципу проводить такую декомпозицию. Как понять, что декомпозиция проведена правильно? Какой принцип положить в её основе?
M>4. Если фантазия не работает , предложите решить имеющиеся проблемы.
Реальные задачи могут потребовать часы и дни для их решения. Не навино ли будет полагать, что кандидат в условиях стресса в течение 5 — 30 минут предложит работоспособное решение?
Благодарю за обстоятельный ответ!
A>Отвлеченные знания вам нах не нужны, поэтому берете дизайн ваших модуей (ну или чуть измененные если там у вас совсем секретно все), набор тербований (тоже можно изменить) и ставите задачу в таком ключе: A>есть система (вот), нужно наиболее быстро добавть в нее новые фичи (эту, эту и вот эту). Что можете предложить в качестве решения?
Сколько времени нужно давать на решение задачи? Вы уверены, что в условиях собеседования кандидат сможет предложить рабочее решение, особенно, если учесть, что решение некоторых задач может занимать часы или даже дни?
Следует ли кандидату дать время на обдумывание задачи и оставить его одного? Или же лучше попросить его комментировать ход решения (т.е. попросить его рассказать, что он делает по шагам)? И, таким образом, оценить подход к решению задачи?
Следует ли кандидата перебивать во время решения, как-то направлять? Или же дать ему время получить результат и оценивать уже результат, а не ход решения, если этот ход решения Вам не понятен?
Здравствуйте, IT, Вы писали:
IT>В данной ситуации не кандидату вопросы задавать нужно, а отвечать на его вопросы. Предоставить ему материалы по проекту: схему БД, структуру модулей, дать на код посмотреть и т.п., объяснить какие именно проблемы в проекте. А дальше отвечать на его вопросы и слушать его предложения.
Допустим, работодатель согласен на такой подход. Но как ему определить, что этот кандидат — именно тот, кто нужно? Что кандидату можно доверять и прислушиваться к его мнению?
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, minorlogic, Вы писали:
M>>1. Предложить разбить на компоненты и связи обределенный функционал , не большой. Например игра шахматы, сервис взаимодействующий с GoogMap для отрисовки карт, и т.п. как можно ближе к прикладной области.
КЛ>Таким образом, один из критериев — архитектор должен уметь выполнять декомпозицию сложной и крупной задачи на легкие и небольшие, сложной системы — на подсистемы и взаимосвязи между ними. Однако этот критерий хорошо, когда ясно, по какому принципу проводить такую декомпозицию. Как понять, что декомпозиция проведена правильно? Какой принцип положить в её основе?
Я и написал в пункте 3
"3. Плавно поговорить о критериях как оценить то или иное решение, предложите оценить несколько разных решений. Как минимум он их должен "чувствовать"."
Т.е. после выполнения декомпозиции обсудить критерии по которым декомпозиция осуществлялась. Я не могу согласится что декомпозиция может быть только одна правильная и все остальные неправильные.
Кроме очевидных критериев таких как (компонент тут класс, модуль , библиотека и т.п. в зависимости от уровня детализации)
1. Сужение ответственности (функциональности ) компонента.
2. Сужение интерфейса компонента.
3. Упрощение графа зависимостей (в идеале дерево).
4. увеличение универсальности компонента.
Есть еще целый ряд специфических знаний и характеристик.
M>>4. Если фантазия не работает , предложите решить имеющиеся проблемы.
КЛ>Реальные задачи могут потребовать часы и дни для их решения. Не навино ли будет полагать, что кандидат в условиях стресса в течение 5 — 30 минут предложит работоспособное решение?
Поэтому я пердлагать в 1. небольшие подзадачи, объяснить и обсудить которые можно в течении получаса.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[5]: Пятничная задача: собеседование архитектора
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, minorlogic, Вы писали:
M>>1. повысить прозрачность системы (архитектура). M>>2. повысить гибкость системы (архитектура).
КЛ>Это всё общие слова. Допустим, система обладает определенными недостатками — ряд функций, которые может выполнять сама, отдаёт на откуп пользователю. Эти конкретные недостатки и нужно исправить в следующей версии. А что такое "прозрачность" и "гибкость" — непонятно.
Достаточно понятно,
Прозрачность системы это когда каждый разработчик знает или может узнать за что отвечает каждый компонент системы.
Гибкость это гибкость, способность быстро меняться с минимальными усилиями для изменения функциональности.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[7]: Пятничная задача: собеседование архитектора
Здравствуйте, Aikin, Вы писали:
A>3) Никакого булщита по поводу метрик, качества кода, 100% покрытия тестами и привержености паттернов (за каждое слово произнесенное в этом ключе я бы давал штрафные баллы).
С этим полностью согласен. Остальные критерии — важны, но они косвеные. Нужен механизм для оценки архитектурных решений или подхода к получению этих решений.
Здравствуйте, minorlogic, Вы писали:
M>И на практике с трудом представляю , как проверить отдельно от остальных именно "навыки архитектора".
Мне представляется, что это всё-таки возможно. Попозже я изложу свой подход. Просто сейчас мне не хочется сбивать обсуждение — интересно узнать мнения коллег.
Здравствуйте, _Dinosaur, Вы писали:
G>>Это значит, что ты всех выслушиваешь и потом выбираешь того, кто тебе больше понравился. _D>Экспертная оценка предполагает оценку на основе группового мнения...
У меня там кавычки были.
"экспертная оценка" в данном контектсе это ироничное название метода тыка
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[3]: Пятничная задача: собеседование архитектора
Опять, блин, никакой конкретики.
КЛ>Сколько времени нужно давать на решение задачи?
Зависит от задачи, конечно. Одни задачи можно решать за 5 мин, вторые несколько дней... Понравившемуся кандидату можно предложить взять задачу "домой".
Но главное в том, что вам не столь важно успел решить задачу кандидат или нет. Вам важно понять как он думает.
КЛ> Вы уверены, что в условиях собеседования кандидат сможет предложить рабочее решение, особенно, если учесть, что решение некоторых задач может занимать часы или даже дни?
Уверен. Даже если он не даст окончательного решения можно понять как он решает задачу. уже это многое может сказать о специалисте.
Кроме того, а вы уверены, что решение, которое нужно разрабатывать пару дней можно будет реализовать за месяц?
КЛ>Следует ли кандидату дать время на обдумывание задачи и оставить его одного? КЛ>Следует ли кандидата перебивать во время решения, как-то направлять? Или же дать ему время получить результат и оценивать уже результат, а не ход решения, если этот ход решения Вам не понятен?
Вот это полностью зависит от кандидата. Одним нужен покой, другим, наоборот, собеседник/оппонент. Мне, лично, нужен собеседник.
Будет хорошо если собеседующий архитектор не будет иметь готового решения. Тогда он сможет включится в процесс.
КЛ>Или же лучше попросить его комментировать ход решения (т.е. попросить его рассказать, что он делает по шагам)? И, таким образом, оценить подход к решению задачи?
Вам важен нужен результат или ход достижения результата? Вполне возможно сам человек не сможет сказать почему он принял какое-либо решение.
Если результат есть, то пусть объясняет почему он выбрал именно это решение. Как/чем это решение поможет сделать нужные изменения в кратчайшие сроки.
Если решения нет, то должны быть хоть какие-то промежуточные результаты. Пусть расскажет какие принципы он хотел заложить в будущий дизайн, какие цели преследовал при его разработке /* например: у нас есть три похожих требования, нужно сделать так-то и так-то чтобы их легко было реализовать. Вот тут у вас хрень какая-то надизайнена, а изменений много. Поэтому сразу же выкидываем кусок нафик/делаем отдельный модуль, интегрируем его так-то и так-то... */.
В общем
Можно предложить задачи с подвохом. Например такие в которых изменения архитектуры не требуются. Новые фичи можно добавить и без изменения архитектуры.
КЛ>С этим полностью согласен. Остальные критерии — важны, но они косвеные. Нужен механизм для оценки архитектурных решений или подхода к получению этих решений.
Что считать косвенным, а что нет?
Если сделать акцент на знаниях кандидата и забыть про горящий проект, то да, согласен, косвенные.
А если все же спасти проект важнее, то наоборот.
СУВ, Aikin
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[4]: Пятничная задача: собеседование архитектора
Здравствуйте, minorlogic, Вы писали:
M>Т.е. после выполнения декомпозиции обсудить критерии по которым декомпозиция осуществлялась. Я не могу согласится что декомпозиция может быть только одна правильная и все остальные неправильные.
Допустим, существует не одна, а несколько правильных декомпозиций. Какие критерии могут быть заложены в их основе?
M>Кроме очевидных критериев таких как (компонент тут класс, модуль , библиотека и т.п. в зависимости от уровня детализации) M>1. Сужение ответственности (функциональности ) компонента. M>2. Сужение интерфейса компонента.
(1) Разве интерфейс компонента не зависит от его функциональности?
M>3. Упрощение графа зависимостей (в идеале дерево).
(2) Разве упрощение графа зависимостей не осуществляется правильным распределением функций между компонентами системы и выстраиванием определенного, желательно, однонаправленного порядка обработки этих функций?
M>4. увеличение универсальности компонента.
(3) Если под универсальностью компонента понимать ограничение на функциональность компонента (например, 1 компонент == 1 функция), но одновременно снятие всяческих ограничений на количество и разнородность обрабатываемых этим компонентом объектов (например, 1 компонент == N объектов == M разных видов объектов), то... см. (4).
(4) Разве (1), (2) и (3) не свидетельствуют о том, что в основу декомпозиции должен быть положен функциональный критерий? Иными словами, перед тем, как проектировать структуру системы, хорошо бы сначала построить её функциональную модель...
Здравствуйте, Aikin, Вы писали:
A>Вам важен нужен результат или ход достижения результата? Вполне возможно сам человек не сможет сказать почему он принял какое-либо решение.
Я смотрю на это дело с точки зрения работодателя (или заказчика). Допустим, я не могу оценить качество архитектурных решений, предложенных кандидатом. Тогда я могу попытаться оценить методологию получения этих решений.
ИМХО, ни одна сложная задача, к которым, безусловно, относится задача проектирования программной системы, не может быть решена без отлаженной методологии. Конечно, нередко архитектор сам до конца не осознает её и применяет интуитивно. Однако наблюдая за ходом решения, особенно, если кандидат будет комментировать свои шаги и обосновывать, почему он поступил так, а не иначе, можно будет составить представление о данной методологии. И о том, позволяет ли она решать необходимые задачи.
Понятно, что методология должна удовлетворять определённым критериям. И эти критерии ведущий собеседование должен понимать. Но в данном случае ему не нужно вникать глубоко в суть методологии, применённой кандидатом. Ему достаточно понять, удовлетворяет ли данная методология нужным критериям.
P.S.: Именно поэтому мне не кажется хорошим вариантом, когда кандидата собеседует опытный архитектор. Дело в том, что у двух гуру могут быть разные подходы к проектированию. В этом случае ведущий собеседование специалист будет оценивать кандидата через призму своего опыта — и просто завалит кандидата, если подход к решению задачи (в простейшем случае, последовательность шагов для получения решения) будет не такой, как у него.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, minorlogic, Вы писали:
M>>Т.е. после выполнения декомпозиции обсудить критерии по которым декомпозиция осуществлялась. Я не могу согласится что декомпозиция может быть только одна правильная и все остальные неправильные. КЛ>Допустим, существует не одна, а несколько правильных декомпозиций. Какие критерии могут быть заложены в их основе?
Кирилл? Я же написал какие ниже.
M>>Кроме очевидных критериев таких как (компонент тут класс, модуль , библиотека и т.п. в зависимости от уровня детализации) M>>1. Сужение ответственности (функциональности ) компонента. M>>2. Сужение интерфейса компонента. КЛ>(1) Разве интерфейс компонента не зависит от его функциональности?
Зависит но не определяет. Одну и ту же функциональность можно представить разными интерфейсами.
M>>3. Упрощение графа зависимостей (в идеале дерево). КЛ>(2) Разве упрощение графа зависимостей не осуществляется правильным распределением функций между компонентами системы и выстраиванием определенного, желательно, однонаправленного порядка обработки этих функций?
Возможно так, мне сложно судить о "правильным распределением функций". Тяжело понять что вы подразумеваете по этим.
M>>4. увеличение универсальности компонента. КЛ>(3) Если под универсальностью компонента понимать ограничение на функциональность компонента (например, 1 компонент == 1 функция), но одновременно снятие всяческих ограничений на количество и разнородность обрабатываемых этим компонентом объектов (например, 1 компонент == N объектов == M разных видов объектов), то... см. (4).
КЛ>(4) Разве (1), (2) и (3) не свидетельствуют о том, что в основу декомпозиции должен быть положен функциональный критерий? Иными словами, перед тем, как проектировать структуру системы, хорошо бы сначала построить её функциональную модель...
Что такое "функциональный критерий" и функциональную модель в вашей терминологии мне неизвестно. Но очевидным для меня , что приступать к архитектуре надо очень хорошо представлять функциональность будущей системы. Но мы то рассматриваем задачу когда функциональность системы хорошо известна ? Или нет ?
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[6]: Пятничная задача: собеседование архитектора
Здравствуйте, minorlogic, Вы писали:
M>Кирилл? Я же написал какие ниже.
Ок.
КЛ>>(1) Разве интерфейс компонента не зависит от его функциональности? M>Зависит но не определяет. Одну и ту же функциональность можно представить разными интерфейсами.
Хорошо. Но Вы согласны с утверждением, что если компонент выполняет больше полезных функций (== обязанностей) из некоторого списка, то и интерфейс у него будет шире, чем у компонента, который выполняет, допустим, одну обязанность из точно того же списка?
M>>>3. Упрощение графа зависимостей (в идеале дерево). КЛ>>(2) Разве упрощение графа зависимостей не осуществляется правильным распределением функций между компонентами системы и выстраиванием определенного, желательно, однонаправленного порядка обработки этих функций? M> Возможно так, мне сложно судить о "правильным распределением функций". Тяжело понять что вы подразумеваете по этим.
В данном случае, я подразумеваю распределение полезных функций (== обязанностей) между компонентами. Например:
1. Мы можем делегировать 1-му классу Фигура 3 полезных функции:
(1) Загрузка (например, из файла).
(2) Визуализация.
(3) Сохранение.
2. А можем — делегировать каждую из этих функций своему классу:
(1) загрузку — Загружальщику,
(2) визуализацию — Рисовальщику,
(3) сохранение — Сохраняльщику.
M>Что такое "функциональный критерий" и функциональную модель в вашей терминологии мне неизвестно. Но очевидным для меня , что приступать к архитектуре надо очень хорошо представлять функциональность будущей системы. Но мы то рассматриваем задачу когда функциональность системы хорошо известна ? Или нет ?
При проектировании или "рефакторинге" (например, в ФСА) обычных технических систем строят как структурную, так и функциональную модели системы.
(1) Структурная модель системы описывает то, из каких компонентов, состоит система, и взаимосвязи между этими компонентами.
(2) Функциональная модель системы описывает то, какие полезные функции выполняет система. В общем случае, это просто список функций или список функций, выстроенных в определённом порядке, например, в порядке их выполнения.
Очевидно, что для того, чтобы создать структурную модель вновь проектируемой системы, для неё сначала необходимо построить функциональную модель, т.к. система создаётся для выполнения неких полезных функций, а не просто так.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, minorlogic, Вы писали:
M>>Кирилл? Я же написал какие ниже. КЛ>Ок.
КЛ>>>(1) Разве интерфейс компонента не зависит от его функциональности? M>>Зависит но не определяет. Одну и ту же функциональность можно представить разными интерфейсами.
КЛ>Хорошо. Но Вы согласны с утверждением, что если компонент выполняет больше полезных функций (== обязанностей) из некоторого списка, то и интерфейс у него будет шире, чем у компонента, который выполняет, допустим, одну обязанность из точно того же списка?
Утверждение часто корректное, но бывают и ситуации когда грамотно выбраная функциональность и интерфейс сильно сильно расширяют функциональность компонента. Например функциональность описанная как "методы обхода 25 разных коллеций и последовательностей" можно реализовать очень толсто и очень гетерогенно. А можно использовать интерфейс "итератор" с компактной функциональностью и узким интерфейсом.
M>>>>3. Упрощение графа зависимостей (в идеале дерево). КЛ>>>(2) Разве упрощение графа зависимостей не осуществляется правильным распределением функций между компонентами системы и выстраиванием определенного, желательно, однонаправленного порядка обработки этих функций? M>> Возможно так, мне сложно судить о "правильным распределением функций". Тяжело понять что вы подразумеваете по этим.
КЛ>В данном случае, я подразумеваю распределение полезных функций (== обязанностей) между компонентами. Например:
КЛ>1. Мы можем делегировать 1-му классу Фигура 3 полезных функции:
КЛ>(1) Загрузка (например, из файла). КЛ>(2) Визуализация. КЛ>(3) Сохранение.
КЛ>2. А можем — делегировать каждую из этих функций своему классу:
КЛ>(1) загрузку — Загружальщику, КЛ>(2) визуализацию — Рисовальщику, КЛ>(3) сохранение — Сохраняльщику.
Тогда нет, неверно. Декомпозиция на компоненты и затем распределение функциональности по ним , не должно быть разделено на этапы. Это один и тот же этап. Отделяя компонент из системы мы отделяем его уже по той ответственности которую он несет. Компонент это не его "название" это его ответственность.
M>>Что такое "функциональный критерий" и функциональную модель в вашей терминологии мне неизвестно. Но очевидным для меня , что приступать к архитектуре надо очень хорошо представлять функциональность будущей системы. Но мы то рассматриваем задачу когда функциональность системы хорошо известна ? Или нет ?
КЛ>При проектировании или "рефакторинге" (например, в ФСА) обычных технических систем строят как структурную, так и функциональную модели системы.
КЛ>(1) Структурная модель системы описывает то, из каких компонентов, состоит система, и взаимосвязи между этими компонентами. КЛ>(2) Функциональная модель системы описывает то, какие полезные функции выполняет система. В общем случае, это просто список функций или список функций, выстроенных в определённом порядке, например, в порядке их выполнения.
КЛ>Очевидно, что для того, чтобы создать структурную модель вновь проектируемой системы, для неё сначала необходимо построить функциональную модель, т.к. система создаётся для выполнения неких полезных функций, а не просто так.
Очевидно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[5]: Пятничная задача: собеседование архитектора
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>P.S.: Именно поэтому мне не кажется хорошим вариантом, когда кандидата собеседует опытный архитектор. Дело в том, что у двух гуру могут быть разные подходы к проектированию. В этом случае ведущий собеседование специалист будет оценивать кандидата через призму своего опыта — и просто завалит кандидата, если подход к решению задачи (в простейшем случае, последовательность шагов для получения решения) будет не такой, как у него.
Плохой интервьюер завалит кандидата, т.к. будет требовать какую то особенную методологию, подход к решению и тд.
Не архитектор завалит архитектора, а плохой интервьюер завалит кандидата.
Материал из Википедии — свободной энциклопедии, -_*
Re[8]: Пятничная задача: собеседование архитектора
Здравствуйте, minorlogic, Вы писали:
M>Утверждение часто корректное, но бывают и ситуации когда грамотно выбраная функциональность и интерфейс сильно сильно расширяют функциональность компонента. Например функциональность описанная как "методы обхода 25 разных коллеций и последовательностей" можно реализовать очень толсто и очень гетерогенно. А можно использовать интерфейс "итератор" с компактной функциональностью и узким интерфейсом.
На мой взгляд, грамотное решение этой задачи кроется не в интерфейсе, а в грамотном определении функций (== обязанностей) и делегировании их соответствующим компонентам.
Чтобы сделать код последовательного обхода коллекции независимым от типа коллекции, нужно, чтобы кто-то предоставлял такие функции:
(1) Получение текущего элемента коллекции
(2) Переход к следующему элементу коллекции
(3) Проверка, достигли ли мы определенного элемента коллекции
Собственно, эти функции и предоставляет компонент итератор.
M>Тогда нет, неверно. Декомпозиция на компоненты и затем распределение функциональности по ним , не должно быть разделено на этапы. Это один и тот же этап. Отделяя компонент из системы мы отделяем его уже по той ответственности которую он несет. Компонент это не его "название" это его ответственность.
Отчасти — согласен, а отчасти — нет. Обычно я проектирую систему в таком порядке:
(1) Создаю функциональную модель
(2) Упорядочиваю функции в порядке выполнения (т.е. описываю процесс, в котором программа или подсистема будет делать то, ради чего создаётся)
(3) Делегирую функции отдельным компонентам, которые, на первых парах, обзываю именами, производными от названия функций
(4) Мысленно проверяю, как будет работать система, не будет ли каких-то сбоев при взаимосвязи между компонентами
(5) Вношу изменения в п.п. 3 и 4 и повторяю п. 5. Иногда, при этом, приходится возвращаться к п. 1, т.к. уточняется/изменяется функциональная модель системы
Всё это, конечно, не точный алгоритм, но некоторое приближение к нему. Мысль, которую я хотел бы подчеркнуть, заключается в том, что процесс выявления функций, делегирования их отдельным компонентам, а затем — перераспределения функций между компонентами — итеративный. И скорее всего, распределение функций между компонентами нельзя выполнить удовлетворительно за один проход. Обязательно нужен этап мысленного моделирования того, как система будет функционировать, чтобы найти возможные сбои.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, minorlogic, Вы писали:
M>>Утверждение часто корректное, но бывают и ситуации когда грамотно выбраная функциональность и интерфейс сильно сильно расширяют функциональность компонента. Например функциональность описанная как "методы обхода 25 разных коллеций и последовательностей" можно реализовать очень толсто и очень гетерогенно. А можно использовать интерфейс "итератор" с компактной функциональностью и узким интерфейсом.
КЛ>На мой взгляд, грамотное решение этой задачи кроется не в интерфейсе, а в грамотном определении функций (== обязанностей) и делегировании их соответствующим компонентам.
КЛ>Чтобы сделать код последовательного обхода коллекции независимым от типа коллекции, нужно, чтобы кто-то предоставлял такие функции:
КЛ>(1) Получение текущего элемента коллекции КЛ>(2) Переход к следующему элементу коллекции КЛ>(3) Проверка, достигли ли мы определенного элемента коллекции
КЛ>Собственно, эти функции и предоставляет компонент итератор.
Конечно, звучит разумно. Но инсайт в этом решении не в самом итераторе, а в том чтобы допустить саму возможность "код последовательного обхода коллекции независимым от типа коллекции". Т.е. самое это допущение и есть великолепное архитектурное решение.
M>>Тогда нет, неверно. Декомпозиция на компоненты и затем распределение функциональности по ним , не должно быть разделено на этапы. Это один и тот же этап. Отделяя компонент из системы мы отделяем его уже по той ответственности которую он несет. Компонент это не его "название" это его ответственность.
КЛ>Отчасти — согласен, а отчасти — нет. Обычно я проектирую систему в таком порядке:
КЛ>(1) Создаю функциональную модель КЛ>(2) Упорядочиваю функции в порядке выполнения (т.е. описываю процесс, в котором программа или подсистема будет делать то, ради чего создаётся) КЛ>(3) Делегирую функции отдельным компонентам, которые, на первых парах, обзываю именами, производными от названия функций КЛ>(4) Мысленно проверяю, как будет работать система, не будет ли каких-то сбоев при взаимосвязи между компонентами КЛ>(5) Вношу изменения в п.п. 3 и 4 и повторяю п. 5. Иногда, при этом, приходится возвращаться к п. 1, т.к. уточняется/изменяется функциональная модель системы
КЛ>Всё это, конечно, не точный алгоритм, но некоторое приближение к нему.
Описанный процесс выглядит разумным. В пункте 4 вы тоже не описали по каким критериям вы будете сравнивать те варианты которые получились а пункте 3.
КЛ>Мысль, которую я хотел бы подчеркнуть, заключается в том, что процесс выявления функций, делегирования их отдельным компонентам, а затем — перераспределения функций между компонентами — итеративный. И скорее всего, распределение функций между компонентами нельзя выполнить удовлетворительно за один проход. Обязательно нужен этап мысленного моделирования того, как система будет функционировать, чтобы найти возможные сбои.
Попытки создать дизайн приложения 1 раз начисто, я бы назвал наивными, или я не достиг таких высот. Мне обычно еще и прототипировать приходится по нескольку раз, то или иное решение. А так же проходить дизайн ревью с коллегами, которые часто указывают на ляпы и ошибки.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[10]: Пятничная задача: собеседование архитектора
Здравствуйте, minorlogic, Вы писали:
M>Конечно, звучит разумно. Но инсайт в этом решении не в самом итераторе, а в том чтобы допустить саму возможность "код последовательного обхода коллекции независимым от типа коллекции". Т.е. самое это допущение и есть великолепное архитектурное решение.
На мой взгляд, получить данное допущение не так уж трудно, если проектировать структуру данных только после того, как построена функциональная модель.
В самом деле, можно рассуждать двумя способами:
(А) Даны различные виды коллекций: массив, список и т.д. Нужно написать функцию последовательного перебора для этих коллекций.
При таком способе, проектировщик "пляшет" от уже имеющихся структур с уже формализованным интерфейсом. Поэтому ему трудно выйти на концепцию итератора и на то, что функция итерации может быть независима от коллекции.
(Б) Имеется функция итерации по некоей коллекции. Нужно подумать, к каким коллекциям она может быть применена.
В этом случае, проектировщик "пляшет" от функции. И он думает над тем, какими должны быть коллекции, чтобы удовлетворять этой функции. При таком подходе, проектировщик выйдет на концепцию итератора с большей вероятностью.
КЛ>>Отчасти — согласен, а отчасти — нет. Обычно я проектирую систему в таком порядке:
КЛ>>(1) Создаю функциональную модель КЛ>>(2) Упорядочиваю функции в порядке выполнения (т.е. описываю процесс, в котором программа или подсистема будет делать то, ради чего создаётся) КЛ>>(3) Делегирую функции отдельным компонентам, которые, на первых парах, обзываю именами, производными от названия функций КЛ>>(4) Мысленно проверяю, как будет работать система, не будет ли каких-то сбоев при взаимосвязи между компонентами КЛ>>(5) Вношу изменения в п.п. 3 и 4 и повторяю п. 5. Иногда, при этом, приходится возвращаться к п. 1, т.к. уточняется/изменяется функциональная модель системы
КЛ>>Всё это, конечно, не точный алгоритм, но некоторое приближение к нему.
M>Описанный процесс выглядит разумным. В пункте 4 вы тоже не описали по каким критериям вы будете сравнивать те варианты которые получились а пункте 3.
Критериев, обычно несколько. Например:
(1) Если усложнить функциональную модель, например, добавить еще одну полезную функцию, не придется ли задавать иной порядок выполнения функций (п. 2)? И не "разлетится ли к чертям" созданная компонентная модель? Т.е. проверяю архитектуру на функциональную расширяемость.
(2) Если поддержать в программе обработку дополнительных объектов (например, генерацию отчетов другого вида или поддержку других форматов входных и выходных данных), то насколько устойчивой окажется построенная модель? Т.е. проверяю архитектуру на объектную расширяемость.
Есть, конечно, и другие критерии.
M>Попытки создать дизайн приложения 1 раз начисто, я бы назвал наивными, или я не достиг таких высот. Мне обычно еще и прототипировать приходится по нескольку раз, то или иное решение. А так же проходить дизайн ревью с коллегами, которые часто указывают на ляпы и ошибки.
Уважаемый Кирилл Лебедев, да пойми, что решать задачу в рамках ее постановки — не в традициях русской школы программирования. Цель российского программиста — не решение задачи, а счастье для всех и мир во всем мире. А ты упорно соврачиваешь все к найму архитектора, хотя к счастью этот путь не ведет, о чем не раз было сказано в ответах.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Итак, какие будут предложения?
В сложившейся ситуации на собеседовании архитекторов будет уместен только один вопрос:
— А есть ли в компании, в которой вы сейчас работаете, открытые позиции для талантливых и способных менеджеров?
Re[4]: Пятничная задача: собеседование архитектора
Здравствуйте, ZevS, Вы писали:
ZS>Уважаемый Кирилл Лебедев, да пойми, что решать задачу в рамках ее постановки — не в традициях русской школы программирования. Цель российского программиста — не решение задачи, а счастье для всех и мир во всем мире. А ты упорно соврачиваешь все к найму архитектора, хотя к счастью этот путь не ведет, о чем не раз было сказано в ответах.
Ну, в конце концов, интересно же, как народ отбирает себе архитекторов на проект. Может, ты станешь исключением из данной традиции и выскажешь свои соображения по задаче?
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Ну, в конце концов, интересно же, как народ отбирает себе архитекторов на проект.
Я давно понял, что ты форумом ошибся
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[5]: Пятничная задача: собеседование архитектора
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, ZevS, Вы писали:
ZS>>Уважаемый Кирилл Лебедев, да пойми, что решать задачу в рамках ее постановки — не в традициях русской школы программирования. Цель российского программиста — не решение задачи, а счастье для всех и мир во всем мире. А ты упорно соврачиваешь все к найму архитектора, хотя к счастью этот путь не ведет, о чем не раз было сказано в ответах.
КЛ>Ну, в конце концов, интересно же, как народ отбирает себе архитекторов на проект.
А может всетаки потрудишься объяснить что ты понимаешь под архитектором. Потому что видима у большинства это понимание не совпадает.
Re[5]: Пятничная задача: собеседование архитектора
Здравствуйте, Кирилл Лебедев, Вы писали:
ZS>>Уважаемый Кирилл Лебедев, да пойми, что решать задачу в рамках ее постановки — не в традициях русской школы программирования. Цель российского программиста — не решение задачи, а счастье для всех и мир во всем мире. А ты упорно соврачиваешь все к найму архитектора, хотя к счастью этот путь не ведет, о чем не раз было сказано в ответах.
КЛ>Ну, в конце концов, интересно же, как народ отбирает себе архитекторов на проект.
Ты мог бы спросить прямо — как собеседовать архитектора, требования к подходу — быстро, надежно, дешево, качественно и тд. Вместо этого ты сначала придумал контекст, потом открестился от него, вдобавок оказалось что тебе нужен не сам подход, а мета-подход
Материал из Википедии — свободной энциклопедии, -_*
Re[6]: Пятничная задача: собеседование архитектора
-_*>Ты мог бы спросить прямо — как собеседовать архитектора, требования к подходу — быстро, надежно, дешево, качественно и тд. Вместо этого ты сначала придумал контекст, потом открестился от него, вдобавок оказалось что тебе нужен не сам подход, а мета-подход
И это повод уводить обсуждение в сторону от основной темы?
Здравствуйте, Aikin, Вы писали:
A>Я давно понял, что ты форумом ошибся
Разве? А мне казалось, что на данном форуме обсуждаются вопросы проектирования, а не вопросы плохого менеджмента...
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, Aikin, Вы писали:
A>>Я давно понял, что ты форумом ошибся КЛ>Разве? А мне казалось, что на данном форуме обсуждаются вопросы проектирования, а не вопросы плохого менеджмента...
Когда говоришь "нанять хорошего Х" вопрос попадает в категорию менеджмента независимо от Х.
Потому что в первую очередь надо придумать формальный проверяемый "хорошести", а это чаще всего метрики. Потом придумать способ как получить эти метрики по кандидату в короткое время. Кроме того надо понимать что если Х предполагает взаимодействие с людьми, то важны не только метрики но и некоторые психологические факторы.
Re[8]: Пятничная задача: собеседование архитектора
Здравствуйте, gandjustas, Вы писали:
G>Когда говоришь "нанять хорошего Х" вопрос попадает в категорию менеджмента независимо от Х.
ИМХО, технические критерии должен давать технический специалист.
G>Потому что в первую очередь надо придумать формальный проверяемый "хорошести", а это чаще всего метрики. Потом придумать способ как получить эти метрики по кандидату в короткое время. Кроме того надо понимать что если Х предполагает взаимодействие с людьми, то важны не только метрики но и некоторые психологические факторы.
Если бы понадобилось оценить психологические факторы, я бы обратился в подраздел "Управление проектами".
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Ну, в конце концов, интересно же, как народ отбирает себе архитекторов на проект. Может, ты станешь исключением из данной традиции и выскажешь свои соображения по задаче?
Критерии подбора в каждом случае свои, универсальных методов подбора любых специалистов, боюсь, не существует. Это лишний раз доказывает текущее обсуждение, в котором тебе предлагают вариант, а ты тут же его отбраковываешь вспоминая очередное ограничение. Это как как загадка "Что у меня в кармане?" — отгадать невозможно.
Re[6]: Пятничная задача: собеседование архитектора
Здравствуйте, ZevS, Вы писали:
ZS>Критерии подбора в каждом случае свои, универсальных методов подбора любых специалистов, боюсь, не существует. Это лишний раз доказывает текущее обсуждение, в котором тебе предлагают вариант, а ты тут же его отбраковываешь вспоминая очередное ограничение. Это как как загадка "Что у меня в кармане?" — отгадать невозможно.
На мой взгляд, любая сложная задача не может быть решена с 1-го раза — поэтому "обсуждение решения" и "уточнение условий" — нормальные действия при решении комплексной задачи.
Кроме того, не заметил, где бы я вводил ограничения при обсуждении решений. Ограничения вводились там, где тема скатывалась в оффтопик. В самом деле, обсуждения вопросов адекватности менеджмента, куда пропал архитектор и пр. — к данной задаче не относятся.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, gandjustas, Вы писали:
G>>Когда говоришь "нанять хорошего Х" вопрос попадает в категорию менеджмента независимо от Х. КЛ>ИМХО, технические критерии должен давать технический специалист.
Должен делать и делает это разные вещи. Формальные оценки — то, в чем творческие люди (коих большинство среди программистов) не сильны, в силу психологии.
G>>Потому что в первую очередь надо придумать формальный проверяемый "хорошести", а это чаще всего метрики. Потом придумать способ как получить эти метрики по кандидату в короткое время. Кроме того надо понимать что если Х предполагает взаимодействие с людьми, то важны не только метрики но и некоторые психологические факторы. КЛ>Если бы понадобилось оценить психологические факторы, я бы обратился в подраздел "Управление проектами".
Тем не менее в зависимости от задач архитектора некоторые психологические факторы могут оказаться очень важными для его работы.
Re[7]: Пятничная задача: собеседование архитектора
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>На мой взгляд, любая сложная задача не может быть решена с 1-го раза — поэтому "обсуждение решения" и "уточнение условий" — нормальные действия при решении комплексной задачи.
Конечно, но и выдавливать информацию по капле — тоже не дело. Размазанные по всей ветке условия никто читать не станет.
КЛ>Кроме того, не заметил, где бы я вводил ограничения при обсуждении решений. Ограничения вводились там, где тема скатывалась в оффтопик. В самом деле, обсуждения вопросов адекватности менеджмента, куда пропал архитектор и пр. — к данной задаче не относятся.
Основные посылы данные тобой касались именно ошибок менеджмента, с технической стороны про проект было сказано почти ничего. Так что, не стоит удивляться тому, что обсуждение сразу ушло в проблемы управления проектом.
Re[7]: Пятничная задача: собеседование архитектора
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, -_*, Вы писали:
КЛ>-_*>Ты мог бы спросить прямо — как собеседовать архитектора, требования к подходу — быстро, надежно, дешево, качественно и тд. Вместо этого ты сначала придумал контекст, потом открестился от него, вдобавок оказалось что тебе нужен не сам подход, а мета-подход КЛ>И это повод уводить обсуждение в сторону от основной темы?
Ты сам направил беседу непойми куда первым же сообщением.
Материал из Википедии — свободной энциклопедии, -_*
Re[8]: Пятничная задача: собеседование архитектора
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Возможно, но что мешает тебе, зная теперь полные условия задачи, включиться в обсуждение и предложить что-либо конструктивное?
Лично мне жалко сил потраченых на решение задачи с неполным и даже некорректным условием.
А если копать глубже, то нежелание узнать критические доп условия уже после того как предложил свое решение задачи.
СУВ, Aikin
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[8]: Пятничная задача: собеседование архитектора
Здравствуйте, ZevS, Вы писали:
ZS>Основные посылы данные тобой касались именно ошибок менеджмента, с технической стороны про проект было сказано почти ничего. Так что, не стоит удивляться тому, что обсуждение сразу ушло в проблемы управления проектом.
Внимание, вопрос: Как Вы будет проводить собеседования с кандидатами на роль архитектора? Какие задания будете им предлагать? На что будете обращать внимание? Что для вас важно, а что не важно?
Предыстория же, ИМХО, просто помогла увести обсуждение задачи в неконструктивное русло. На мой взгляд, в том числе и потому, что смащно высказаться об ошибках менеджмента гораздо легче, чем разруливать реальную проблему.
P.S.: Даже ты, зная теперь реальную задачу, предпочитаешь обсуждать мои ошибки в её формулировке вместо того, чтобы предложить конструктивное решение.
Здравствуйте, Aikin, Вы писали:
A>Лично мне жалко сил потраченых на решение задачи с неполным и даже некорректным условием.
За всю свою 14-летнюю практику в разработке коммерческого ПО не встречал ещё, чтобы сложная — в техническом плане — задача с первого раза была бы поставлена правильно и корректно.
Умение преобразовывать задачу из формулировки клиента к форме, пригодной для выработки технического решения — ИМХО, первый ключевой навык архитектора и/или технического лида.
A>А если копать глубже, то нежелание узнать критические доп условия уже после того как предложил свое решение задачи.
Умение пересматривать своё первичное решение в процессе дальнейшего разбора задачи — второй ключевой навык архитектора и/или технического лида.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, Aikin, Вы писали:
A>>Лично мне жалко сил потраченых на решение задачи с неполным и даже некорректным условием.
КЛ>За всю свою 14-летнюю практику в разработке коммерческого ПО не встречал ещё, чтобы сложная — в техническом плане — задача с первого раза была бы поставлена правильно и корректно.
КЛ>Умение преобразовывать задачу из формулировки клиента к форме, пригодной для выработки технического решения — ИМХО, первый ключевой навык архитектора и/или технического лида.
Мне за работу деньги платят. В чем мой понт вытягивать требования из тебя?
СУВ, Aikin
ЗЫ КЛ>Умение пересматривать своё первичное решение в процессе дальнейшего разбора задачи — второй ключевой навык архитектора и/или технического лида.
Кто сказал, что я не прересмотрел своего решения? Есть у меня наметки, вот только превращать их в нечто более существенное нет желания.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[9]: Пятничная задача: собеседование архитектора
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>-_*>Ты сам направил беседу непойми куда первым же сообщением.
КЛ>Возможно, но что мешает тебе, зная теперь полные условия задачи, включиться в обсуждение и предложить что-либо конструктивное?
Теперь у меня пропал интерес что либо обсуждать здесь и я переключился на другую тему.
Материал из Википедии — свободной энциклопедии, -_*
Re[9]: Пятничная задача: собеседование архитектора
КЛ>Внимание, вопрос: Как Вы будет проводить собеседования с кандидатами на роль архитектора? Какие задания будете им предлагать? На что будете обращать внимание? Что для вас важно, а что не важно?
КЛ>Предыстория же, ИМХО, просто помогла увести обсуждение задачи в неконструктивное русло. На мой взгляд, в том числе и потому, что смащно высказаться об ошибках менеджмента гораздо легче, чем разруливать реальную проблему.
Ахринеть!
Т.е. ты со своей "14-летней практике в разработке коммерческого ПО" не видишь разницы между
разработкой архитектуры для нового проекта
адаптировать существующую архитектуру к изменившимся/новым требованиям
за 1 месяц разобраться в каша-архитектуре, внести в нее изменения, донести их до разработчиков, реализовать/помочь ее реализовать
?????
Я был более высокого мнения о тебя, ты уж извини.
СУВ, Aikin
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[9]: Пятничная задача: собеседование архитектора
Здравствуйте, Aikin, Вы писали:
A>Мне за работу деньги платят. В чем мой понт вытягивать требования из тебя?
Заметь, что за увод хода обсуждения от первоначальной темы тебе тоже не платят денег. И даже не просят делать это. Однако ты этим занимаешься. Интересно, зачем?
A>Кто сказал, что я не прересмотрел своего решения? Есть у меня наметки, вот только превращать их в нечто более существенное нет желания.
ИМХО, благие намерения — это конечно хорошо. Но в данном случае важны действия. Если нет у тебя желания отвечать по-существу, то зачем разводить офтопик?
Здравствуйте, -_*, Вы писали:
КЛ>>Возможно, но что мешает тебе, зная теперь полные условия задачи, включиться в обсуждение и предложить что-либо конструктивное?
-_*>Теперь у меня пропал интерес что либо обсуждать здесь и я переключился на другую тему.
Однако ты продолжаешь здесь писать не по существу вопроса. Зачем? Это отнимает и твоё, и моё время. И заспамливает ветвь дискуссии бессмысленными и бесполезными сообщениями, что помешает людям, столкнувшимся с проблемой, аналогичной той, что вынесена в обсуждение, найти среди этого "спама" полезную для себя рекомендацию.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, -_*, Вы писали:
КЛ>-_*>Ты сам направил беседу непойми куда первым же сообщением.
КЛ>Возможно, но что мешает тебе, зная теперь полные условия задачи, включиться в обсуждение и предложить что-либо конструктивное?
Я перечитал всю тему, но до полных условий далеко.
Давай чтобы все было в одном посте:
1)Какие проблемы в проекте? (пользователи жалуются — указать на что, большие трудозатраты на поддержку — указать какие именно задачи отбирают много времени)
2)Каков источник проблем? (неверно поняты требования, неверно выбраны средства для реализации, неверно реализованы требования, множество ошибок при реализации, недостаточные пользовательские качества: медленно и\или некрасиво работает)
3)Как по вашему можно эти проблемы исправить без полного переписывания?
4)Почему нужно брать человека для исправления этим проблем и нельзя обойтись теми кто есть?
5)Какие кроме этого обязанности должны быть у человека чтобы он назывался Архитектором?
Re[10]: Пятничная задача: собеседование архитектора
Здравствуйте, gandjustas, Вы писали:
G>Я перечитал всю тему, но до полных условий далеко.
G>Давай чтобы все было в одном посте:
Ок, попробую ответить на твои вопросы. Хотя, и мне хотелось бы подчеркнуть ещё раз, в данной теме не нужно искать техническое решение проблем, с которыми столкнулся заказчик. Нужно просто подсказать, как отбирать архитектора (или тех. лидера — предположим, что заказчик ошибается с названием позиции) на проект, который предполагает рефакторинг.
G>1)Какие проблемы в проекте? (пользователи жалуются — указать на что, большие трудозатраты на поддержку — указать какие именно задачи отбирают много времени)
Проект состоит из (условно) двух составляющих:
(1) картографические данные, хранящиеся в БД на сервере;
(2) визуализация этих картографических данных, хранящаяся на другом сервере.
Дело в том, что с частью (1) работает огромное число пользователей. А наша система относится к части (2), с которой работает лишь небольшое подмножество пользователей части (1).
Основная проблема заключается в том, что пользователи части (2) вынуждены синхронизировать вручную визуальную информацию с актуальной картографической.
Хотелось бы, чтобы в новой версии системы эта проблема была бы устранена. Чтобы для любой картографической информации всегда бы имелась актуальная графическая.
G>2)Каков источник проблем? (неверно поняты требования, неверно выбраны средства для реализации, неверно реализованы требования, множество ошибок при реализации, недостаточные пользовательские качества: медленно и\или некрасиво работает)
Система (1) является приватной. К ней нет доступа. В принципе, можно было бы растеризовать в фоновом режиме, но непонятно, как узнать, что информация в системе (1) обновлена. Нет никаких сервисов, позволяющих узнать это.
G>3)Как по вашему можно эти проблемы исправить без полного переписывания?
А и не надо переписывать систему. Нужно только её перепроектировать, чтобы визуальная информация обновлялась автоматически.
Для этого, уже на мой взгляд, возможны два варианта:
1) Система (2) автоматически следит за данными в системе (1) и, если они обновились, перегенерирует растровое изображения изменённых участков. Недостаток: система (2) должна хранить данные из системы (1) для того, чтобы узнать, что они обновились.
2) Встроиться каким-либо образом между пользователями системы (1) и конечной базой данных для системы (1), чтобы отлавливать запросы на изменение данных. Если данные изменяются, то посылать уведомление системе (2) для того, чтобы она перегенерировала растровые изображения для изменённых данных.
G>4)Почему нужно брать человека для исправления этим проблем и нельзя обойтись теми кто есть?
Этого я не знаю.
G>5)Какие кроме этого обязанности должны быть у человека чтобы он назывался Архитектором?
Возможно, тут требуется не только архитектор, но и тим-лидер. Но в данной теме хотелось бы обсудить тестирование кандидата, как проектировщика.
Здравствуйте, Кирилл Лебедев, Вы писали:
A>>Мне за работу деньги платят. В чем мой понт вытягивать требования из тебя? КЛ>Заметь, что за увод хода обсуждения от первоначальной темы тебе тоже не платят денег. И даже не просят делать это. Однако ты этим занимаешься. Интересно, зачем?
1) Я не уводил обсуждение. Я ответил на твой вопрос "Возможно, но что мешает тебе, зная теперь полные условия задачи, включиться в обсуждение и предложить что-либо конструктивное?"
2) Ответы в стиле Re[9]: Пятничная задача: собеседование архитектора
3) Я знаю тебя как грамотного архитектора сообщения которого с удовольствием читаю. Поэтому считаю, что не все еще потеряно и ты еще сможешь сесть, подумать над требованиями к задаче и выдать ее нам, а не ждать пока мы ее из тебя высосем (уверен, что у тебя этих требований до сих пор нет).
A>>Кто сказал, что я не прересмотрел своего решения? Есть у меня наметки, вот только превращать их в нечто более существенное нет желания. КЛ>ИМХО, благие намерения — это конечно хорошо. Но в данном случае важны действия. Если нет у тебя желания отвечать по-существу, то зачем разводить офтопик?
Очевидно же: потому что есть желание "разводить офтопик" (с моей точки зрения "показать что ты не прав")
СУВ, Aikin
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[13]: Пятничная задача: собеседование архитектора
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Заметь, что за увод хода обсуждения от первоначальной темы тебе тоже не платят денег. И даже не просят делать это. Однако ты этим занимаешься. Интересно, зачем?
А по-приколу.
Re[11]: Пятничная задача: собеседование архитектора
G>>5)Какие кроме этого обязанности должны быть у человека чтобы он назывался Архитектором? КЛ>Возможно, тут требуется не только архитектор, но и тим-лидер. Но в данной теме хотелось бы обсудить тестирование кандидата, как проектировщика.
Я думаю тут не требуется ни тот, ни другой. Вам просто нужен программист, который умеет работать с конкретной СУБД, где лежит ваша база. Он сможет сделать наиболее эффективный контроль изменений данных (вплоть до тупого поллинга с некоторым интервалом для видимых объектов).
И собеседовать его надо упирая именно на эти знания и умения.
А модные названия вроде "архитектор" это как раз от того что менеджмент не понимает сути проблем и хочет просто чуда (в виде нового "архитектора"), которое эти проблемы решит.
Re[12]: Пятничная задача: собеседование архитектора
Здравствуйте, gandjustas, Вы писали:
G>Я думаю тут не требуется ни тот, ни другой. Вам просто нужен программист, который умеет работать с конкретной СУБД, где лежит ваша база. Он сможет сделать наиболее эффективный контроль изменений данных (вплоть до тупого поллинга с некоторым интервалом для видимых объектов).
Вся фишка в том, что доступ к этой СУБД возможен только через Apache Tomcat. Напрямую доступ к БД закрыт, т.к. она приватна и принадлежит другой компании. Доступ только на общих основаниях.
G>И собеседовать его надо упирая именно на эти знания и умения.
Возможно, как уже тут писалось, заказчику нужен просто грамотный технический лид, который будет разруливать проблемы.
G>А модные названия вроде "архитектор" это как раз от того что менеджмент не понимает сути проблем и хочет просто чуда (в виде нового "архитектора"), которое эти проблемы решит.
Согласен, но в настоящий момент заказчик ищет архитектора и в качестве тестового вопроса предлагает спроектировать текстовый редактор с поддержкой хайлайта и проверкой правописания за 5 минут.
Здравствуйте, Aikin, Вы писали:
A>3) Я знаю тебя как грамотного архитектора сообщения которого с удовольствием читаю. Поэтому считаю, что не все еще потеряно и ты еще сможешь сесть, подумать над требованиями к задаче и выдать ее нам, а не ждать пока мы ее из тебя высосем (уверен, что у тебя этих требований до сих пор нет).
Собственно говоря, я уже попытался это сделать здесь
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, gandjustas, Вы писали:
G>>Я думаю тут не требуется ни тот, ни другой. Вам просто нужен программист, который умеет работать с конкретной СУБД, где лежит ваша база. Он сможет сделать наиболее эффективный контроль изменений данных (вплоть до тупого поллинга с некоторым интервалом для видимых объектов).
КЛ>Вся фишка в том, что доступ к этой СУБД возможен только через Apache Tomcat. Напрямую доступ к БД закрыт, т.к. она приватна и принадлежит другой компании. Доступ только на общих основаниях.
Это только упрощает ситуацию.
Если не умеет приложение на Tomcat отдавать изменения с заданного времени, то остается один вариант — poll по тем объектам, которые сейчас видны.
G>>И собеседовать его надо упирая именно на эти знания и умения. КЛ>Возможно, как уже тут писалось, заказчику нужен просто грамотный технический лид, который будет разруливать проблемы.
Да это собственно и не лид нужен, разве что в команде вообще нету лида. Но это уже другая проблема.
G>>А модные названия вроде "архитектор" это как раз от того что менеджмент не понимает сути проблем и хочет просто чуда (в виде нового "архитектора"), которое эти проблемы решит. КЛ>Согласен, но в настоящий момент заказчик ищет архитектора и в качестве тестового вопроса предлагает спроектировать текстовый редактор с поддержкой хайлайта и проверкой правописания за 5 минут.
Re[11]: Пятничная задача: собеседование архитектора
. Буду признателен за конструктивный ответ.
Кирилл, это не те вопросы, на которые я жду ответ. Согласен, они прояснили вашу ситуацию, но если бы ты хотел узнать как разрешить эту ситуацию ты бы обратился в форум "управление проектами". Нет, тебя интересует по каким критериям нужно выбирать архитектора (верное ли это решение тебе не важно). Я правильно понял?
Тогда, грубо, 3 категории задач:
разработкой архитектуры для нового проекта
адаптировать существующую архитектуру к изменившимся/новым требованиям
за 1 месяц разобраться в каша-архитектуре, внести в нее изменения, донести их до разработчиков, реализовать/помочь ее реализовать
Ведь совершенно очевидно, что третья категория требует немного другие навыки от кандидата, чем две предыдущие.
Так же совершенно очевидно что некий "Астронафт Архитектуры", с успехом прошедший, собеседование (о да!, он прочитал массу книг, знает массу подходов/паттернов, ...). Который, фиг с ним, идеально решит задачу №1, завалит решение второй ибо перепишет все нафик.
Так вот у меня вопрос: мы собеседуем кандидата на основании общих знаний или же знаний, но в применении к конкретной ситуации (может даже 4ой и 5ой)?
В зависимости от целей, поставленых перед будущим архитектором, будут важны (более важны) разные критерии. (ну а в 3м случае знания архитектора не так уж и важны, но об мы подумаем этом после ответа на мой вопрос)
КЛ>Нужно просто подсказать, как отбирать архитектора (или тех. лидера — предположим, что заказчик ошибается с названием позиции) на проект, который предполагает рефакторинг.
Косвенно, по процитированному, я могу сказать что у нас, все же, ситуация 3
СУВ, Aikin
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[11]: Пятничная задача: собеседование архитектора
Кандидат обязан:
— очень хорошо занать и иметь большой опыт работы с технологиями, используемыми в проекте
— иметь опыть создания и, что возможно более важно, рефакторинга распределенных систем (желательно со сходной архитектурой)
— понимать на что идет и иметь желание добиться результата
Работодатель обязан:
— максимально честно и полно рассказать о проекте и проблемах в нем
— обозначить цель, ограничения, перспективы развития проекта
— ознакомить с возможностями: состав команды, перспективы найма дополнительных сотрудников, степень доверия кандидату
Re[14]: Пятничная задача: собеседование архитектора
Здравствуйте, gandjustas, Вы писали:
КЛ>>Вся фишка в том, что доступ к этой СУБД возможен только через Apache Tomcat. Напрямую доступ к БД закрыт, т.к. она приватна и принадлежит другой компании. Доступ только на общих основаниях. G>Это только упрощает ситуацию. G>Если не умеет приложение на Tomcat отдавать изменения с заданного времени, то остается один вариант — poll по тем объектам, которые сейчас видны.
Насколько я понял из слов заказчика, генерация нового растрового изображения — операция длительная. Может занимать часы.
G>Да это собственно и не лид нужен, разве что в команде вообще нету лида. Но это уже другая проблема.
Могу ошибаться, но вроде заказчик предполагал возложение на архитектора и лидерских обязанностей.
КЛ>>Согласен, но в настоящий момент заказчик ищет архитектора и в качестве тестового вопроса предлагает спроектировать текстовый редактор с поддержкой хайлайта и проверкой правописания за 5 минут. G>
Реально технические специалисты заказчика не ограничивают время на проектирование редактора. Но если в течение первых 5 мин. решения кандидат не переходит от постановки задачи к рисованию архитектуры (компонентов и взаимосвязей между ними), то они начинают перебивать и выносят вердикт: "ну-у, это слишком долго".
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, -_*, Вы писали:
КЛ>>>Возможно, но что мешает тебе, зная теперь полные условия задачи, включиться в обсуждение и предложить что-либо конструктивное?
КЛ>-_*>Теперь у меня пропал интерес что либо обсуждать здесь и я переключился на другую тему.
КЛ>Однако ты продолжаешь здесь писать не по существу вопроса. Зачем? Это отнимает и твоё, и моё время. И заспамливает ветвь дискуссии бессмысленными и бесполезными сообщениями, что помешает людям, столкнувшимся с проблемой, аналогичной той, что вынесена в обсуждение, найти среди этого "спама" полезную для себя рекомендацию.
Создай лучше новый тред.
Материал из Википедии — свободной энциклопедии, -_*
Re[12]: Пятничная задача: собеседование архитектора
Здравствуйте, Aikin, Вы писали:
A>Нет, тебя интересует по каким критериям нужно выбирать архитектора (верное ли это решение тебе не важно). Я правильно понял?
Совершенно правильно.
A>Тогда, грубо, 3 категории задач: A>
A> разработкой архитектуры для нового проекта A> адаптировать существующую архитектуру к изменившимся/новым требованиям A> за 1 месяц разобраться в каша-архитектуре, внести в нее изменения, донести их до разработчиков, реализовать/помочь ее реализовать A>
Думаю, что имеется смесь ситуаций (2) и (3), только времени выделено больше — от полугода до года, имхо.
A>Так же совершенно очевидно что некий "Астронафт Архитектуры", с успехом прошедший, собеседование (о да!, он прочитал массу книг, знает массу подходов/паттернов, ...). Который, фиг с ним, идеально решит задачу №1, завалит решение второй ибо перепишет все нафик.
Нужно модифицировать систему, но не переписать её с нуля. Понятно, что при модификации будут правки и в software design'е.
A>Так вот у меня вопрос: мы собеседуем кандидата на основании общих знаний или же знаний, но в применении к конкретной ситуации (может даже 4ой и 5ой)? A>В зависимости от целей, поставленых перед будущим архитектором, будут важны (более важны) разные критерии. (ну а в 3м случае знания архитектора не так уж и важны, но об мы подумаем этом после ответа на мой вопрос)
Мне в этой ситуации интересен общий подход к проведению собеседования с архитектором:
(1) на разработку нового проекта с нуля;
(2) на масштабный рефакторинг готового проекта.
Понятно, что:
1) просить кандидата спроектировать текстовый редактор за 5 мин.,
2) длительно рассказывать о текущих проблемах и пытаться выяснить предложения кандидата по их решению тоже за 5 мин.
— в целом, провальные и неадекватные стратегии.
Вот меня и интересует, какая стратегия в сложившейся ситуации будет более адекватной.
-_*>Создай лучше новый тред.
Поддерживаю оратора!
Кирилл, создай новый тред. А еще лучше 2.
В одном будем обсуждать как собеседовать архитектора, а во второй что можно сделать в конкретной ситуации (ибо у меня тоже есть по этому вопросу мысли, но это, вроде как, офтоп).
СУВ, Aikin
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[11]: Пятничная задача: собеседование архитектора
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Я так понимаю, что просто непонятно, как её проверять. Система (2) не содержит в себе данных системы (1) — не с чем сравнивать.
Таки можно задавать технические вопросы? Тогда я задам
1) Как часто меняются данные в (1) (судя по тому, что 2 пересчитывает несколько часов, то редко, но с другой стороны что мешает пересчитать только часть?)
2) Насколько устаревшие данные допустимы для (2)?
3) Каков объем данных из (1) необходим (2)?
4) (1) совсем поменять невозможно? (соберитесь бандой двоек и вкатите им требование. Скорее всего не только вам нужен запрос на актуальность данных)
Хватит пока
СУВ, Aikin
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[13]: Пятничная задача: собеседование архитектора
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, minorlogic, Вы писали:
M>>А почему не планировать проверку актуальности информации в (1) когда информацию запросили из (2) ?
КЛ>Я так понимаю, что просто непонятно, как её проверять. Система (2) не содержит в себе данных системы (1) — не с чем сравнивать.
Может именно это и надо организовать ? хранить хеши по данным из (1) в (2), потому что из контекста видно что данные из (1) в (2) поступают но потом забываются за ненадобностью.
Или получать из (1) версию данных ? или дату последней модификации ?
Все решения чисто технические и завияст от конкретики (1) и (2), а архитектуры тут нету
Кстати офтоп , а что за рендеринг такой дикий который часами работает ? Вроде как и не много данных у современных GIS чтобы часы тратить, в релтайме все летает.
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[11]: Пятничная задача: собеседование архитектора
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Благодарю за конструктивный ответ!
Я вот спросил тебя про сроки переноса, ты не ответил. Между тем, это важный момент. Расклад такой — очевидно, может возникнуть ситуация, когда команда скажет "ифы(поллинг...) лучше(хуже...) чем ...", т.е. просто не согласиться с архитектором. Отсюда
1. сроки сжатые — стало быть архитектору нужно будет иметь скил быстро проводить свои решения. Следовательно, упор нужно делать на коммуникативность, умение логически обосновывать, убеждать, располагать к себе и тд.
2. сроки достаточно комфортные — здесь баланс лучше сместить в сторону технических скилов.
Мне реально лень строить дерево вариантов по тем вопросам, которые я тебе задавал. Может ты все таки будешь отвечать на вопросы или, хотя бы, объяснять, почему вопрос не должен стоять на повестке ?
Материал из Википедии — свободной энциклопедии, -_*
Re[12]: Пятничная задача: собеседование архитектора
Здравствуйте, ZevS, Вы писали:
ZS>Кандидат обязан: ZS>- очень хорошо занать и иметь большой опыт работы с технологиями, используемыми в проекте
В последние несколько лет стал замечать, что опыт работы с определенными технологиями, платформами и даже языками программирования не так уж важен по сравнению с общей технической подготовкой и умением решать действительно сложные задачи. Многие мои опытные коллеги с легкостью осваивали новые технологии и переходили с одной технологии на другую и, при этом, продолжали эффективно решать технические задачи.
С другой стороны, некоторые коллеги, которые может и были знакомы с требуемыми технологиями, но не умели производительно и эффективно работать, так по-прежнему и продолжали работать — неэффективно и непроизводительно.
Поэтому я бы в качестве п.1 поставил бы требование — умение эффективно и производительно решать сложные технические задачи. И далее уже думал бы над тем, как его проверять.
Здравствуйте, Aikin, Вы писали:
A>1) Как часто меняются данные в (1) (судя по тому, что 2 пересчитывает несколько часов, то редко, но с другой стороны что мешает пересчитать только часть?)
Не знаю, но полагаю, что часто. У системы (1) в 10 — 100 раз больше пользователей, чем у системы (2).
A>2) Насколько устаревшие данные допустимы для (2)?
Сейчас допустимо. Но именно это и хочется исправить.
A>3) Каков объем данных из (1) необходим (2)?
Не знаю.
A>4) (1) совсем поменять невозможно? (соберитесь бандой двоек и вкатите им требование. Скорее всего не только вам нужен запрос на актуальность данных)
Думаю, что нет. Система (1) представляет ценность своей БД и информацией в ней. Поэтому система (2) ей и пользуется.
Здравствуйте, minorlogic, Вы писали:
M>Может именно это и надо организовать ? хранить хеши по данным из (1) в (2), потому что из контекста видно что данные из (1) в (2) поступают но потом забываются за ненадобностью.
Не знаю точно, но, думаю, такой вариант возможен.
M>Или получать из (1) версию данных ? или дату последней модификации ?
Думаю, так нельзя сделать. Было бы можно — давно бы сделали.
M>Все решения чисто технические и завияст от конкретики (1) и (2), а архитектуры тут нету
Согласен.
M> Кстати офтоп , а что за рендеринг такой дикий который часами работает ? Вроде как и не много данных у современных GIS чтобы часы тратить, в релтайме все летает.
Не знаю.
-_*>Я вот спросил тебя про сроки переноса, ты не ответил. Между тем, это важный момент. Расклад такой — очевидно, может возникнуть ситуация, когда команда скажет "ифы(поллинг...) лучше(хуже...) чем ...", т.е. просто не согласиться с архитектором. Отсюда
Думаю, сроки достаточно комфортные — от полугода до года. С месяцем я загнул.
Здравствуйте, Кирилл Лебедев, Вы писали:
ZS>>Кандидат обязан: ZS>>- очень хорошо занать и иметь большой опыт работы с технологиями, используемыми в проекте
КЛ>В последние несколько лет стал замечать, что опыт работы с определенными технологиями, платформами и даже языками программирования не так уж важен по сравнению с общей технической подготовкой и умением решать действительно сложные задачи. Многие мои опытные коллеги с легкостью осваивали новые технологии и переходили с одной технологии на другую и, при этом, продолжали эффективно решать технические задачи.
Архитектор просто обязан быть знаком с множеством технологий ведь ему придется находить техническое решение проблемы при заданных ограничениях. И знакомство только с миром виндовз не сильно поможет ему при проектировании под юникс. Более, в твоем случае необходим человек, который очень быстро сумеет разобраться в текущим состоянии проекта и найти решение. Тут хорошее знание технологий (их особенностей, подводных камней) может оказаться критическим.
Re[13]: Пятничная задача: собеседование архитектора
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, minorlogic, Вы писали:
M>>А почему не планировать проверку актуальности информации в (1) когда информацию запросили из (2) ?
КЛ>Я так понимаю, что просто непонятно, как её проверять. Система (2) не содержит в себе данных системы (1) — не с чем сравнивать.
И второй вариант вдогонку , ускорить рендеринг + всегда обновлять данные запрошенные у (2), но сперва показывать имеющиеся данные и новые подкачивать по мере поступления. Так например делает клиент google Eath
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[11]: Пятничная задача: собеседование архитектора
Здравствуйте, minorlogic, Вы писали:
M>а вообще пипец , как можно приступать к разработке системы если ключевые вопросы не были решены и прототипированы .
Не знаю. Возможно, сопровождение программы отдали компании на аутсорсинг. Может, это вообще не их система.
Как это проверить на собеседовании — не совсем ясно.
Если нам не помогут, то мы тоже никого не пощадим.
.
