DAX - черновик
Тема является продолжением дискуссии из этой ветки: http://axforum.info/forums/showthread.php?t=74041.
Во-первых, я рекомендую точнее определиться со специалистом, который необходим. В команде могут пригодиться все, важно ее "правильно готовить". Зачастую, мы все сконцентрированы на разработке и модификации ERP-систем, поэтому, конечно, основные навыки желательно иметь по работе именно с данной системой. Но, зачастую, дополнительные навыки очень важны - особенно это касается web-разработки и администрирования SQL-сервера. Однако, если человек работал с отчетными системами, интеграционной шиной, MED / CAD или ТСД - эти навыки могут оказаться очень востребованными.
Надо определиться с уровнем разработчика. Как я уже указывал прошлой ветке, я разделял соискателей на
* "кодеров" ("поставь задачу - я решу, если хорошо разжевать" - идеально для работы в консалтинге, где принято разделение труда и необходимо брать деньги с клиента не только за разработку кода, но и за детализирование описание модификаций. Почему так - обсуждалось не раз, методология и все такое. Тут вам не Agile)
* "разработчиков" (сначала пойму задачу, изучу настройки, часть так / часть из кода, пойму что от меня хотят, как это работает в другом модуле, попробую переубедить или поискать другой воркэраунд или запрограммировать малой кровью). Я предпочитал, конечно, именно их - как можно заметить, второй - это программист, которому лень быть консультантом. Так я получал 2-в-1. Даже 3 в 1, т.к. отсутствует процесс коммуникации и тестирование легче. Подобные люди стоят хоть и подороже, но в разы эффективнее. Для работы на клиенте, возможно, это более предпочтительно. Но часть работы консультантов приходится брать на себя ключевым пользователям. Фактически, это работает когда вас ставят перед выбором кого нанимать, консультанта или разработчика. При этом консультант, который пишет код, заведомо проиграет толковому разработчику, который может работать консультантом. Просто ему лень - зачем мне описывать поля, алгоритмы и что надо сделать, есть я быстрее все это напишу в системе? Минус этого решения - обычно в постоянном цейноте про документирование разработок можно забыть система превращается в огромный черный ящик. Но и это мы уже не раз обсуждали.
* Стажер. Может быть не очень юн, просто с данной системой дела не имел. Из него может получиться (и, кстати, получался не раз) - очень толковый разработчик - консультант. Смотря как "дать путевку в жизнь": ставить рисовать отчеты или вовлекать в сложные разработки, давая простые куски, потом давать на решение отдельный задачи, выделяя 1-1,5 часа каждый вечер, совестно разбирая кто что сегодня сделал, как можно было решить по-другому и что можно было улучшить.
Я, честно, стал опасаться кудесников, которые могут решить подобные задачи, но не знают основных паттернов в Dax - FormLetter'a там или ничего не слышали хорошего про SettleNow.
А еще лучше - по бизнесу задать вопросы. Тогда понятно, кто это - кодер (поставь задачу - я решу, если хорошо разжевать) или Программист (.
желательно
Если мы хотим получить "готов"
Во-первых, я рекомендую точнее определиться со специалистом, который необходим. В команде могут пригодиться все, важно ее "правильно готовить". Зачастую, мы все сконцентрированы на разработке и модификации ERP-систем, поэтому, конечно, основные навыки желательно иметь по работе именно с данной системой. Но, зачастую, дополнительные навыки очень важны - особенно это касается web-разработки и администрирования SQL-сервера. Однако, если человек работал с отчетными системами, интеграционной шиной, MED / CAD или ТСД - эти навыки могут оказаться очень востребованными.
Надо определиться с уровнем разработчика. Как я уже указывал прошлой ветке, я разделял соискателей на
* "кодеров" ("поставь задачу - я решу, если хорошо разжевать" - идеально для работы в консалтинге, где принято разделение труда и необходимо брать деньги с клиента не только за разработку кода, но и за детализирование описание модификаций. Почему так - обсуждалось не раз, методология и все такое. Тут вам не Agile)
* "разработчиков" (сначала пойму задачу, изучу настройки, часть так / часть из кода, пойму что от меня хотят, как это работает в другом модуле, попробую переубедить или поискать другой воркэраунд или запрограммировать малой кровью). Я предпочитал, конечно, именно их - как можно заметить, второй - это программист, которому лень быть консультантом. Так я получал 2-в-1. Даже 3 в 1, т.к. отсутствует процесс коммуникации и тестирование легче. Подобные люди стоят хоть и подороже, но в разы эффективнее. Для работы на клиенте, возможно, это более предпочтительно. Но часть работы консультантов приходится брать на себя ключевым пользователям. Фактически, это работает когда вас ставят перед выбором кого нанимать, консультанта или разработчика. При этом консультант, который пишет код, заведомо проиграет толковому разработчику, который может работать консультантом. Просто ему лень - зачем мне описывать поля, алгоритмы и что надо сделать, есть я быстрее все это напишу в системе? Минус этого решения - обычно в постоянном цейноте про документирование разработок можно забыть система превращается в огромный черный ящик. Но и это мы уже не раз обсуждали.
* Стажер. Может быть не очень юн, просто с данной системой дела не имел. Из него может получиться (и, кстати, получался не раз) - очень толковый разработчик - консультант. Смотря как "дать путевку в жизнь": ставить рисовать отчеты или вовлекать в сложные разработки, давая простые куски, потом давать на решение отдельный задачи, выделяя 1-1,5 часа каждый вечер, совестно разбирая кто что сегодня сделал, как можно было решить по-другому и что можно было улучшить.
Я, честно, стал опасаться кудесников, которые могут решить подобные задачи, но не знают основных паттернов в Dax - FormLetter'a там или ничего не слышали хорошего про SettleNow.
А еще лучше - по бизнесу задать вопросы. Тогда понятно, кто это - кодер (поставь задачу - я решу, если хорошо разжевать) или Программист (.
желательно
Если мы хотим получить "готов"