Ваша ошибка в том, что вы ограничили свои обязанности разработкой и поддержкой. Самообразование тоже входит в обязаности ведущего программиста.
Когда — в рабочее время. За чей счет — за счет работодателя. Но — самостоятельно. Программист — это звучит гордо, неужели нельзя освоить какую-нибудь бухгалтерию или ценные бумаги?
что я плохо работаю, т.к. не заметил его достижений
В таком случае за 12 лет в IT я хороших менеджеров еще не видел. Мне всегда повышали зарплату только или под угрозой увольнения, или при смене места работы. Где бы я ни работал — на оборонку, в средней компании, в международном банке, в стартапе.
Ну что можно написать в должностной инструкции для программиста? Разве что добросовестно трудиться 8 часов в день. Распределение времени между самообразованием, изучением бизнес-процессов, анализом требований, уточнений плохо сформулированных требований, кодингом, поддержкой инфраструктуры разработки и т.п. формализировать не получится.
Конечно, бывает вариант бизнес аналитик -> аналитик -> ТЗ -> архитектор -> разработчик. Этим путем стараются следовать или компании с высочайшей культурой разработки, или компании вообще без неё. Но качественное ТЗ очень трудоемко в написании, а некачественное ТЗ приводит к хаосу.
Минусовал не я, но говорить человеку, что он "ноет", когда он пытается донести какую-то свою проблему, это грязный прием)
К тому же, "делай что сказано, не нравится — до свидания" — признак плохих контор. Этот подход работает для офисного люда или там бухгалтерии, где от работников требуется выполнять должностную инструкцию. Но не для IT.
По зарплатам есть hh.ru
По малому бизнесу — по статистике, первые два года существования малый бизнес находится на грани безубыточности. Затем прибыль может колебаться, а ЗП надо платить каждый месяц.
Установка "подчиненный не может получать больше своего начальника" это эквивалент печально известного "я начальник ты дурак".
В современном IT практикуют "каждый выполняет свои обязанности" и горизонтальный рост помимо вертикального. У Васи были свои обязанности, у вас — свои. А получилось что? Вы ушли, Вася вместо того, что он делать умеет, начал делать то, чего он делать не умеет.
Даже на заводах у работяг есть разряды, и токарь 6 разряда может зарабатывать, как начальник цеха. В малом бизнесе наемные работники частенько получают больше собственника. А вот в отечественной корпоративщине постаринке.
На Западе есть движение под названием open business — они ратуют за то, что полная открытость бизнеса это преимущество. Вот пример, как одна из таких компаний вычисляет зарплату: https://open.buffer.com/salary-formula/
Я сейчас рассуждаю с использованием полномочий. Кто может модифицировать ключевые бизнес-процессы? Систему мотивации, завязанную на бюджет. Систему управления и, тем более, цели организации?
Посыл статьи — если все работодатели одинаковы, всё будет зависеть от нанимающего менеджера. Как на рынке — если все газировки одинаковы, то продажи зависят от рекламы.
Вот только не будет во всех банках одинаковое IT, т.к. в 21 веке IT составляет важное конкурентное преимущество банка. Скорость и качество обслуживания клиентов, надежность, качество анализа данных. Всё это влияет на себестоимость и риски, и, следовательно, на цены, качество и ассортимент услуг.
Как идея с прототипами работает на практике? Проблема "суррогатов" не в том, что бизнес-заказчику будет неудобно им пользоваться — ему как раз будет удобно. Проблема в том, что любая качественная система построена на некотором дизайне, некоторых фундаментальных ограничениях. Например, "не давать прямой доступ в базу другим приложениям" или "не запускать аналитические запросы на OLTP базе".
"суррогат" именно этим и опасен — тем, что разрушает архитектуру системы, усложняя поддержку и уменьшая быстродействие. И коварен тем, что со стороны бизнес-заказчика это выглядит "программист не хочет работать".
Согласен с автором про публичность — если человек приходит к тебе с проблемой, нужно понять человека и проблему, а не создавать ему дополнительные трудности, чтобы он не создал трудности уже вам. И, в идеале, не кодить функционал, а решать проблемы.
Я считаю, что путь "бизнес-программиста" идеален. Человек, называющий себя сеньором, должен знать не только что он пишет, но и зачем и для кого. Куча плюшек за простое желание учиться.
Но как прототипирование может в этом помочь — непонятно.
Я думаю, не-айтишникам значительно проще защитить от несанкцированного доступа блокнот, чем файл на компе. Это нетривиальная задача. Например, с файрволлом всё не так просто — трояны наловчились отправлять данные через браузер, через виндовые системные сервисы и т.п.
Самый "правильный" вариант — отдельное устройство с шифрованием) Телефон например, если не ставить на него что попало.
Да, это общая проблема всех менеджеров паролей, особенно самых популярных. Про "штуку" — верится с трудом в юзермоде. Заточенный под вас троян всё это обойдет.
Я пришел к выводу, что менеджер паролей надо или иметь в бумажном виде, или на отдельном устройстве, или писать самому.
Познавательно, красиво и… опасно. Появятся трояны, специализированные для кражи всех сохраненных паролей из браузера. Принцип достаточно прост — "подсмотреть" мастер-пароль при вводе кейлоггером или пропатчить исполняемый код браузера на диске/непосредственно в памяти. Когда пользователь введет мастер-пароль, все его пароли будут расшифрованы и переданы.
Вопрос к тем, кто в теме. Какую сумму в биткоинах можно фактически продать за доллары? 100? 100? 10к? больше? И где?
Ваша ошибка в том, что вы ограничили свои обязанности разработкой и поддержкой. Самообразование тоже входит в обязаности ведущего программиста.
Когда — в рабочее время. За чей счет — за счет работодателя. Но — самостоятельно. Программист — это звучит гордо, неужели нельзя освоить какую-нибудь бухгалтерию или ценные бумаги?
В таком случае за 12 лет в IT я хороших менеджеров еще не видел. Мне всегда повышали зарплату только или под угрозой увольнения, или при смене места работы. Где бы я ни работал — на оборонку, в средней компании, в международном банке, в стартапе.
Ну что можно написать в должностной инструкции для программиста? Разве что добросовестно трудиться 8 часов в день. Распределение времени между самообразованием, изучением бизнес-процессов, анализом требований, уточнений плохо сформулированных требований, кодингом, поддержкой инфраструктуры разработки и т.п. формализировать не получится.
Конечно, бывает вариант бизнес аналитик -> аналитик -> ТЗ -> архитектор -> разработчик. Этим путем стараются следовать или компании с высочайшей культурой разработки, или компании вообще без неё. Но качественное ТЗ очень трудоемко в написании, а некачественное ТЗ приводит к хаосу.
Минусовал не я, но говорить человеку, что он "ноет", когда он пытается донести какую-то свою проблему, это грязный прием)
К тому же, "делай что сказано, не нравится — до свидания" — признак плохих контор. Этот подход работает для офисного люда или там бухгалтерии, где от работников требуется выполнять должностную инструкцию. Но не для IT.
По зарплатам есть hh.ru
По малому бизнесу — по статистике, первые два года существования малый бизнес находится на грани безубыточности. Затем прибыль может колебаться, а ЗП надо платить каждый месяц.
Установка "подчиненный не может получать больше своего начальника" это эквивалент печально известного "я начальник ты дурак".
В современном IT практикуют "каждый выполняет свои обязанности" и горизонтальный рост помимо вертикального. У Васи были свои обязанности, у вас — свои. А получилось что? Вы ушли, Вася вместо того, что он делать умеет, начал делать то, чего он делать не умеет.
Даже на заводах у работяг есть разряды, и токарь 6 разряда может зарабатывать, как начальник цеха. В малом бизнесе наемные работники частенько получают больше собственника. А вот в отечественной корпоративщине постаринке.
На Западе есть движение под названием open business — они ратуют за то, что полная открытость бизнеса это преимущество. Вот пример, как одна из таких компаний вычисляет зарплату: https://open.buffer.com/salary-formula/
И статья на википедии: https://en.wikipedia.org/wiki/Open_business
если все завидующие поувольняются, то, быть может, это плюс?
В нормальных банках весь дресс-код для айтишников — не маячить в шортах и шлепках.
Я сейчас рассуждаю с использованием полномочий. Кто может модифицировать ключевые бизнес-процессы? Систему мотивации, завязанную на бюджет. Систему управления и, тем более, цели организации?
Посыл статьи — если все работодатели одинаковы, всё будет зависеть от нанимающего менеджера. Как на рынке — если все газировки одинаковы, то продажи зависят от рекламы.
Вот только не будет во всех банках одинаковое IT, т.к. в 21 веке IT составляет важное конкурентное преимущество банка. Скорость и качество обслуживания клиентов, надежность, качество анализа данных. Всё это влияет на себестоимость и риски, и, следовательно, на цены, качество и ассортимент услуг.
У вас какой-то замгендира получился, или как минимум начальник отдела.
Вот только на IPO у акционеров есть какие-то права, гарантируемые юридически, а как насчет ICO?
Как идея с прототипами работает на практике? Проблема "суррогатов" не в том, что бизнес-заказчику будет неудобно им пользоваться — ему как раз будет удобно. Проблема в том, что любая качественная система построена на некотором дизайне, некоторых фундаментальных ограничениях. Например, "не давать прямой доступ в базу другим приложениям" или "не запускать аналитические запросы на OLTP базе".
"суррогат" именно этим и опасен — тем, что разрушает архитектуру системы, усложняя поддержку и уменьшая быстродействие. И коварен тем, что со стороны бизнес-заказчика это выглядит "программист не хочет работать".
Согласен с автором про публичность — если человек приходит к тебе с проблемой, нужно понять человека и проблему, а не создавать ему дополнительные трудности, чтобы он не создал трудности уже вам. И, в идеале, не кодить функционал, а решать проблемы.
Я считаю, что путь "бизнес-программиста" идеален. Человек, называющий себя сеньором, должен знать не только что он пишет, но и зачем и для кого. Куча плюшек за простое желание учиться.
Но как прототипирование может в этом помочь — непонятно.
План по захвату мира:
Есть хоть одна причина, по которой этот план не будет реализован?
Радует, что наш корпоративный сектор дорос до ESB. С нетерпением жду внедрения SOA в следующем десятилетии.
так вот чем занимаются студенты в ночь перед сессией
Я думаю, не-айтишникам значительно проще защитить от несанкцированного доступа блокнот, чем файл на компе. Это нетривиальная задача. Например, с файрволлом всё не так просто — трояны наловчились отправлять данные через браузер, через виндовые системные сервисы и т.п.
Самый "правильный" вариант — отдельное устройство с шифрованием) Телефон например, если не ставить на него что попало.
Да, это общая проблема всех менеджеров паролей, особенно самых популярных. Про "штуку" — верится с трудом в юзермоде. Заточенный под вас троян всё это обойдет.
Я пришел к выводу, что менеджер паролей надо или иметь в бумажном виде, или на отдельном устройстве, или писать самому.
Познавательно, красиво и… опасно. Появятся трояны, специализированные для кражи всех сохраненных паролей из браузера. Принцип достаточно прост — "подсмотреть" мастер-пароль при вводе кейлоггером или пропатчить исполняемый код браузера на диске/непосредственно в памяти. Когда пользователь введет мастер-пароль, все его пароли будут расшифрованы и переданы.