если бы докладчики писали статьи, мы бы публиковали статьи))
хорошо, хоть доклады делают интересные))
если поставить требование для докладчиков подавать полный текст статьи перед конференцией — боюсь, у нас будет 2.5 докладчика))
спасибо за комментарий по сути :)
ну мне кажется в этом наука и состоит — чтобы искать, какие вещи в общении с заказчиками работают, а какие — нет
это как и в отношениях между людьми — правильные слова и действия — не гарантия успешных отношений, большое значение имеют эмоции, харизма человека и другие личные качества, неописуемые правилами. Мне кажется автор в стать и попыталась сказать про то, что нужно быть нестандартным и ищущим. И всё это, конечно, на базе правильных технических достижений — всё делать в сроки, хорошо и качественно, т.е. как минимум всегда надо выполнить обещания, а как максимум — подарить приятные впечатления заказчику, чтобы ему захотелось продолжить работать именно с вами, а не искать другого подрядчика, который будет быстрей-дешевле или ещё что-либо…
ну автор в докладе так выразился, но мне кажется, что статья всё же про ИТ :)
в принципе автора понять можно, она акцент в докладе делала про маркетинг-клиентинг, а не на работу бизнес-аналитика, написание ТЗ и прочие более «технические» штуки…
с первым пунктом соглашусь не полностью
если у вас очень объёмная задача, то создание своего языка тоже может быть оправданно, язык должен давать:
1. возможность решения задачи на языке предметной области, особенно если требования предметной области часто меняются (вспомните 1С — аля платформа DSL языка для бухгалтеров, согласитесь писать все эти бухгалтерские заморочки на C# или того хуже на С++ было бы куда страшней и менее понятно).
2. универсальность языка — любую задачу можно нарисовать на нём
3. экспресивность языка — вы легко читаете задачу на метаязыке, как-будто задача написана на языке предметной области и т.п.
Суть такая если у вас исходная задача на языке предметной области:
Зарплата сотрудника = отработанное время * нормочас и т.п.
То в случае, если вы пишете чисто на коде, используя конструкции SQL, Linq и т.п. То задачу вы, наверное, решите, но корреляции между вашим кодом и языком предметной области будет очень мало, и в случае если у вас поменяется формулировка задачи (новые термины, связи между ними и т.п.) — то очень высока вероятность, что ваш код придётся очень серьёзно переделывать под нужды новых терминов.
В случае же, если вы имеете свой метаязык, который уже достаточно глубоко эмулирует язык предметной области и вы действительно решаете задачу на этом метаязыке: Salary(Person) ::= WorkedTime * PayPerHour… — то в случае, если задача будет переформулирована, есть вероятность, что вы новое решение запишите просто повторяя формулировку новой задачи при помощи средств метаязыка, без необходимости серьёзной перестройки своей метамодели (ведь она уже эмулирует задачу! только немного расширить надо). Ну и, конечно, чтение кода на метаязыке должно быть практически таким же комфортным, как чтение оригинальной постановки задачи на языке предметной области, т.е. это может делать даже не программист, а эксперт предметной области.
ребята делали реализацию приложения на Java + макросы и затем, при помощи MPS автоматом конвертили полученный код в Object C, который компили уже на iOS
хорошая абстракция и их взаимосвязи помогает структурировать разрозненные знания в голове
не кто не спорит, что здесь люди умные, но разговаривать надо на одном языке и понимать термины единым образом.
мне кажется сертификация больше имеет значения для более сложных и объёмных вещей, а не таких попсовых, как знания на уровние Software Tester. Вот, например, если ты заявляешь, что ты владеешь ITIL или методологиями RUP, MSF или знание вендорских специальных технологий-софта и т.п. То наличие сертификата говорит, что ты не только прочитал книжку об этой вещи, но и сдал какой-никакой экзамен. А в компании может и не найтись спеца, который смог бы тебя поинтервьюировать компетентно. Другое дело — каковы были требования экзамена и насколько он хорошо отражает факт знания предметной области. Это уже зависит о самой сертификации.
хорошо, хоть доклады делают интересные))
если поставить требование для докладчиков подавать полный текст статьи перед конференцией — боюсь, у нас будет 2.5 докладчика))
Так и здесь дилетант, получающий зарплату — ещё не профессионал, как мне кажется :)
softwarepeople.ru/blog/2013/05/28/analystdays-2013
analyst.by/articles/analystdays2012review
okiseleva.blogspot.com/2013/06/analyst-days-2.html
и ряд других
ну мне кажется в этом наука и состоит — чтобы искать, какие вещи в общении с заказчиками работают, а какие — нет
это как и в отношениях между людьми — правильные слова и действия — не гарантия успешных отношений, большое значение имеют эмоции, харизма человека и другие личные качества, неописуемые правилами. Мне кажется автор в стать и попыталась сказать про то, что нужно быть нестандартным и ищущим. И всё это, конечно, на базе правильных технических достижений — всё делать в сроки, хорошо и качественно, т.е. как минимум всегда надо выполнить обещания, а как максимум — подарить приятные впечатления заказчику, чтобы ему захотелось продолжить работать именно с вами, а не искать другого подрядчика, который будет быстрей-дешевле или ещё что-либо…
в принципе автора понять можно, она акцент в докладе делала про маркетинг-клиентинг, а не на работу бизнес-аналитика, написание ТЗ и прочие более «технические» штуки…
если у вас очень объёмная задача, то создание своего языка тоже может быть оправданно, язык должен давать:
1. возможность решения задачи на языке предметной области, особенно если требования предметной области часто меняются (вспомните 1С — аля платформа DSL языка для бухгалтеров, согласитесь писать все эти бухгалтерские заморочки на C# или того хуже на С++ было бы куда страшней и менее понятно).
2. универсальность языка — любую задачу можно нарисовать на нём
3. экспресивность языка — вы легко читаете задачу на метаязыке, как-будто задача написана на языке предметной области и т.п.
habrahabr.ru/post/142491
Суть такая если у вас исходная задача на языке предметной области:
Зарплата сотрудника = отработанное время * нормочас и т.п.
То в случае, если вы пишете чисто на коде, используя конструкции SQL, Linq и т.п. То задачу вы, наверное, решите, но корреляции между вашим кодом и языком предметной области будет очень мало, и в случае если у вас поменяется формулировка задачи (новые термины, связи между ними и т.п.) — то очень высока вероятность, что ваш код придётся очень серьёзно переделывать под нужды новых терминов.
В случае же, если вы имеете свой метаязык, который уже достаточно глубоко эмулирует язык предметной области и вы действительно решаете задачу на этом метаязыке: Salary(Person) ::= WorkedTime * PayPerHour… — то в случае, если задача будет переформулирована, есть вероятность, что вы новое решение запишите просто повторяя формулировку новой задачи при помощи средств метаязыка, без необходимости серьёзной перестройки своей метамодели (ведь она уже эмулирует задачу! только немного расширить надо). Ну и, конечно, чтение кода на метаязыке должно быть практически таким же комфортным, как чтение оригинальной постановки задачи на языке предметной области, т.е. это может делать даже не программист, а эксперт предметной области.
codefest.ru/program/2012-03/the-practice-of-MPS/
ребята делали реализацию приложения на Java + макросы и затем, при помощи MPS автоматом конвертили полученный код в Object C, который компили уже на iOS
не кто не спорит, что здесь люди умные, но разговаривать надо на одном языке и понимать термины единым образом.