Одно другому не мешает, кстати.
Эта статья сделана по мотивам моих выступлений на эту тему.
Соглашусь. Информации в сети так много, что ради нее нет смысла ходить на конференции в качестве слушателя. А вот за эмоциями, мотивацией и связями — вполне. Так что, да, шоу.
Я интроверт :)
Название темы, конечно, чуть провокационное.
Бросать, естественно, не стоит. Гораздо интереснее слушать того, кто на практике знает, о чем говорит
Всякие матрицы компетенций склоняют многих к достижению формальных показателей
Так и не надо превращать наполнение матрицы в формализм и обязательно привязывать к KPI.
Матрица компетенций — прежде всего, инструмент для руководителя по диагностике узких мест. А расшивать узкие места лучше всё ж через постоянную практику, а не от оценке к оценке.
Вот пример.
Есть у меня сотрудник. С провалами в ИБ и работе с БД.
БД — ключевая компетенция. ИБ — дополнительная.
Для меня это означает, что в течение квартала задачки по написанию запросов при создании сервисов нужно почаще решать этим человеком. И заодно попросить поисследовать наличие SQL-инъекций в том коде, который он будет писать в течение этого квартала.
Он может и не узнать, что я эти задачи даю осознанно.
Но в процессе их решения ему в любом случае придется чуть прокачаться в проблемных темах.
Люди с недостаточной мотивацией встречаются постоянно.
Ради интереса посмотрел статистику по одному из наших клиентов.
Обследовали полтора десятка ребят уровня Senior+
В ~45% случаев ребята отвечали, что данный навык им развивать неинтересно.
Разные причины — кто-то боится нового, кто-то не умеет быстро разбираться в сложных вещах, у кого-то задач выше крыши, кто-то просто перегорел.
Рецепт один:
1. В каждом конкретном случае разбираемся в конкретной причине отсутствия мотивации
2. Понимаем, можем ли устранить причину, как быстро и сколько будет стоить (часов коллеги-эксперта, денег).
3. Если можем и недорого, мотивируем.
4. Если не можем, ищем того, кто относится к навыку позитивно или нейтрально.
К сожалению, инфантилизм — это вообще повсеместная история, поэтому к взрослости не всегда удается достучаться. Ну и перегретость ИТ-рынка в России не способствует
Московский политех через проектное обучение идет по этому пути.
ФГОСы, конечно, тяжелая история, но тут возможен такой же лайфхак, как и при реализации госконтрактов — часть команды сконцентрирована только на создании продукта, а другая — только на бумажках, освобождая первую.
Одни учат, вторые готовят бумажки.
Тоже, кстати, распределение на основе компетенций.
При этом, компании, зачастую, не готовы работать с удалёнными разработчиками
Удаленные разработчики — отдельная история, со своей спецификой.
Действительно, не каждая команда готова на это пойти, не каждой удается нормально выстроить такое взаимодействие. Для больших компаний могут наложиться и какие-то особенности рабочего процесса. Опять же — одно дело, когда зарекомендовавший себя успешной работой сотрудник переходит на удаленное взаимодействие по личным обстоятельствам, другое дело — брать на нее нового разработчика — «кота в мешке» — который может пропасть перед дедлайном. Кто-то на себя такие риски готов брать, кто-то нет.
Вы сами достаточно полно ответили на свой вопрос.
Мне особо нечего добавить.
Моё мнение по поводу и PhoneGap, и Xamarin — если подобные продукты позволяют какой-нибудь компании или разработчику быстро выйти на рынок со своим приложением в первой версии, то их стоит использовать. «Выстрелит» приложение, наберет свою аудиторию — хорошо, потом уже можно или дальше обходиться данными продуктами или уже вкладываться с нативную разработку. Не «выстрелит» — и ладно, можно так же оперативно переходить к следующему приложению.
Опять же тот же PhoneGap вполне можно рассматривать как следующий шаг в эволюции от мобильной версии сайта к его представлению в виде приложения для смартфона.
Статья получилась и так достаточно большой, очень о многом сказать получилось лишь в общих словах. User Experience — область вообще достаточно интересная и непростая. И заслуживает больше, чем пары фраз.
Возможно, знаете, возможно, нет — Mail.Ru этой темой достаточно плотно занимается, мы постоянно проводим мероприятия на эту тему, думаю, очередная UX-среда не за горами.
Если кто-то из моих коллег из области проектирования интерфейсов заглянет в эту статью, думаю, они вам много что смогут рассказать или подискутировать по каким-то вопросам. Так что, если что-то конкретное хочется обсудить, оставляйте комментарии, постараемся ответить.
Ну а что можно думать о кросс-платформенных инструментах для мобильной разработки?
В целом то же самое, что о кросс-платформенных решениях в других областях разработки ПО. У них есть своя ниша, они часто позволяют снизить время вхождения на рынок. Но, к сожалению, как только доходит до нюансов, может оказаться, что они перестают справляться с задачами и никакой универсальностью уже не пахнет.
Xamarin в этом смысле не исключение.
Да, всё в целом неплохо, но есть некоторые ограничения, как относительно кода, так и относительно UI. Ядро-то может быть кросс-платформенным, но как только дойдет до интерфейса, все равно без использования нативных функций (читай «нативных разработчиков») конкретной оси обойтись сложновато. Сколько там того переносимого кода получится? Половина? Две трети? А если в приложении основные акценты именно на особенностях разработки UI под конкретную платформу?
В общем, всё сильно зависит от задач. Где-то Xamarin подойдет больше, где-то меньше.
Где-то вообще может подойти практически идеально. Где-то не проживет дальше версии 1.0 конкретного приложения. Серебряной пули всё еще не придумали.
Впрочем, я не готов говорить сразу за всех «менеджеров крупных компаний»™, могу сказать лишь о приложениях своего направления — мы не используем этот продукт, хотя, конечно, знаем о нем и с интересом следим, что у них будет дальше.
Да, абсолютно верно. Без слаженной работы всех, кто делает приложение, успешный продукт может не получиться. И часто именно интерфейс может повлиять на успешность. Поэтому очень важна и работа тех, кто продумывает интерфейсы, и тех, кто реализует. Хорошо, если в команде с этим все хорошо (как у нас, в e-commerce проектах Мэйла). Для новичков — имеет смысл обязательно обратить внимание на этот момент.
Паш, добавь в качестве семинара или в качестве основного материала рассказ об основных способах хранения деревьев. Я думал, что ты такое даешь, и очень удивился, когда студенты четвертого семестра попросили рассказать. У меня ушло 15-20 минут беглого обзора.
Поговорите с вашим работодателем. Предложите ему выплачивать вам на 10 порядков больше 100 000 в месяц. Все указанные числа — в двоичной системе. После этого посмотрим на ваше отношение к «в IT порядок — это степепь двойки».
Как бы ни старались айтишники выпячивать себя интеллектуалами, для которых существует только двоичная система, в обычной жизни зарплату все же любят получать вполне себе в десятичной. Поэтому нефиг показывать свой снобизм. В мире людей «порядок» — это степень не двойки, а десятки.
А я нелинейно и увеличиваю. А в соответствии с изменившимся влиянием конкретного разработчика на снижение каких-то рисков компании.
Да они и на этой работают.
Точно. Но тут опять возникают риски — учет роста рынка, учет стоимости поиска более эффективных ресурсов. Уже несколько другого плана, но возникают. Именно для снижения этих рисков зарплата и увеличивается. Однако, если, скажем, потенциальные риски я оцениваю не очень высоко, то на увеличение зарплаты могу и не пойти. И даже рекомендовать компании расстаться с сотрудником, если стоимость рисков от его пребывания на работе выше чем стоимость рисков, которые он компенсирует своей работой.
Не-не-не, Дэвид Блейн.
Программисты стоят ровно столько, сколько платит им работодатель.
Это максимально объективная оценка.
Все прочие нематериальные — исключительно для ЧСВ самого разработчика, а не для объективной оценки.
Не надо себе так сильно льстить — наша стоимость не равна стоимости рисков, которые мы можем закрыть.
Потому что у рисков есть еще и вероятность их возникновения. И на эту вероятность влияют как действия программистов, так и действия других людей. Но редко так, чтобы разница достигала хотя бы двух порядков.
И только в таком аспекте имеет смысл рассматривать стоимость программиста — как стоимость снижения вероятности возникновения рисков. Отсюда и дифференциация зарплат.
Эта статья сделана по мотивам моих выступлений на эту тему.
Соглашусь. Информации в сети так много, что ради нее нет смысла ходить на конференции в качестве слушателя. А вот за эмоциями, мотивацией и связями — вполне. Так что, да, шоу.
Название темы, конечно, чуть провокационное.
Бросать, естественно, не стоит. Гораздо интереснее слушать того, кто на практике знает, о чем говорит
Так и не надо превращать наполнение матрицы в формализм и обязательно привязывать к KPI.
Матрица компетенций — прежде всего, инструмент для руководителя по диагностике узких мест. А расшивать узкие места лучше всё ж через постоянную практику, а не от оценке к оценке.
Вот пример.
Есть у меня сотрудник. С провалами в ИБ и работе с БД.
БД — ключевая компетенция. ИБ — дополнительная.
Для меня это означает, что в течение квартала задачки по написанию запросов при создании сервисов нужно почаще решать этим человеком. И заодно попросить поисследовать наличие SQL-инъекций в том коде, который он будет писать в течение этого квартала.
Он может и не узнать, что я эти задачи даю осознанно.
Но в процессе их решения ему в любом случае придется чуть прокачаться в проблемных темах.
Ради интереса посмотрел статистику по одному из наших клиентов.
Обследовали полтора десятка ребят уровня Senior+
В ~45% случаев ребята отвечали, что данный навык им развивать неинтересно.
Разные причины — кто-то боится нового, кто-то не умеет быстро разбираться в сложных вещах, у кого-то задач выше крыши, кто-то просто перегорел.
Рецепт один:
1. В каждом конкретном случае разбираемся в конкретной причине отсутствия мотивации
2. Понимаем, можем ли устранить причину, как быстро и сколько будет стоить (часов коллеги-эксперта, денег).
3. Если можем и недорого, мотивируем.
4. Если не можем, ищем того, кто относится к навыку позитивно или нейтрально.
К сожалению, инфантилизм — это вообще повсеместная история, поэтому к взрослости не всегда удается достучаться. Ну и перегретость ИТ-рынка в России не способствует
ФГОСы, конечно, тяжелая история, но тут возможен такой же лайфхак, как и при реализации госконтрактов — часть команды сконцентрирована только на создании продукта, а другая — только на бумажках, освобождая первую.
Одни учат, вторые готовят бумажки.
Тоже, кстати, распределение на основе компетенций.
Удаленные разработчики — отдельная история, со своей спецификой.
Действительно, не каждая команда готова на это пойти, не каждой удается нормально выстроить такое взаимодействие. Для больших компаний могут наложиться и какие-то особенности рабочего процесса. Опять же — одно дело, когда зарекомендовавший себя успешной работой сотрудник переходит на удаленное взаимодействие по личным обстоятельствам, другое дело — брать на нее нового разработчика — «кота в мешке» — который может пропасть перед дедлайном. Кто-то на себя такие риски готов брать, кто-то нет.
Мне особо нечего добавить.
Моё мнение по поводу и PhoneGap, и Xamarin — если подобные продукты позволяют какой-нибудь компании или разработчику быстро выйти на рынок со своим приложением в первой версии, то их стоит использовать. «Выстрелит» приложение, наберет свою аудиторию — хорошо, потом уже можно или дальше обходиться данными продуктами или уже вкладываться с нативную разработку. Не «выстрелит» — и ладно, можно так же оперативно переходить к следующему приложению.
Опять же тот же PhoneGap вполне можно рассматривать как следующий шаг в эволюции от мобильной версии сайта к его представлению в виде приложения для смартфона.
Возможно, знаете, возможно, нет — Mail.Ru этой темой достаточно плотно занимается, мы постоянно проводим мероприятия на эту тему, думаю, очередная UX-среда не за горами.
Если кто-то из моих коллег из области проектирования интерфейсов заглянет в эту статью, думаю, они вам много что смогут рассказать или подискутировать по каким-то вопросам. Так что, если что-то конкретное хочется обсудить, оставляйте комментарии, постараемся ответить.
В целом то же самое, что о кросс-платформенных решениях в других областях разработки ПО. У них есть своя ниша, они часто позволяют снизить время вхождения на рынок. Но, к сожалению, как только доходит до нюансов, может оказаться, что они перестают справляться с задачами и никакой универсальностью уже не пахнет.
Xamarin в этом смысле не исключение.
Да, всё в целом неплохо, но есть некоторые ограничения, как относительно кода, так и относительно UI. Ядро-то может быть кросс-платформенным, но как только дойдет до интерфейса, все равно без использования нативных функций (читай «нативных разработчиков») конкретной оси обойтись сложновато. Сколько там того переносимого кода получится? Половина? Две трети? А если в приложении основные акценты именно на особенностях разработки UI под конкретную платформу?
В общем, всё сильно зависит от задач. Где-то Xamarin подойдет больше, где-то меньше.
Где-то вообще может подойти практически идеально. Где-то не проживет дальше версии 1.0 конкретного приложения. Серебряной пули всё еще не придумали.
Впрочем, я не готов говорить сразу за всех «менеджеров крупных компаний»™, могу сказать лишь о приложениях своего направления — мы не используем этот продукт, хотя, конечно, знаем о нем и с интересом следим, что у них будет дальше.
Как бы ни старались айтишники выпячивать себя интеллектуалами, для которых существует только двоичная система, в обычной жизни зарплату все же любят получать вполне себе в десятичной. Поэтому нефиг показывать свой снобизм. В мире людей «порядок» — это степень не двойки, а десятки.
Спросили — ответил.
Вы счастливый человек, вам так мало надо для поднятия настроения.
А я нелинейно и увеличиваю. А в соответствии с изменившимся влиянием конкретного разработчика на снижение каких-то рисков компании.
Точно. Но тут опять возникают риски — учет роста рынка, учет стоимости поиска более эффективных ресурсов. Уже несколько другого плана, но возникают. Именно для снижения этих рисков зарплата и увеличивается. Однако, если, скажем, потенциальные риски я оцениваю не очень высоко, то на увеличение зарплаты могу и не пойти. И даже рекомендовать компании расстаться с сотрудником, если стоимость рисков от его пребывания на работе выше чем стоимость рисков, которые он компенсирует своей работой.
Сложно это всё — управление коллективом…
Обычно я прошу повысить зарплату моим сотрудникам.
Откройте для себя волшебный мир алгебры, асимптот, гипербол и прочих логарифмов :)
Программисты стоят ровно столько, сколько платит им работодатель.
Это максимально объективная оценка.
Все прочие нематериальные — исключительно для ЧСВ самого разработчика, а не для объективной оценки.
Не надо себе так сильно льстить — наша стоимость не равна стоимости рисков, которые мы можем закрыть.
Потому что у рисков есть еще и вероятность их возникновения. И на эту вероятность влияют как действия программистов, так и действия других людей. Но редко так, чтобы разница достигала хотя бы двух порядков.
И только в таком аспекте имеет смысл рассматривать стоимость программиста — как стоимость снижения вероятности возникновения рисков. Отсюда и дифференциация зарплат.