Если тебе нравится то, что ты делаешь, ты можешь и 12-14 часов в день спокойно посвящать этому занятию. Избитая фраза «найди работу по душе и тебе никогда в жизни не придется работать», но оч применима.
А на счет оффлайновой офисной работы (опять же, если она тебе по душе) потери фокуса выливаются в 10-14 часов «нахождения» в офисе. Потому что дела-то тоже надо делать, не только фокус терять на разговорах и прогулках.
Если ты работаешь исключительно «за деньги» и без особого удовольствия от самого процесса, то да, 8 честных часов это сложновато, да и не нужно — есть куча других мест где можно работать <=4 и получать норм деньги
Очень редко. Обычно так делаю когда у человека падает производительность по сравнению с другими членами команды или есть какие-то подозрения в недобросовестности.
Например был у меня один человек который хитрыми способами читил трекер, я заметил значительную просадку в его производительности и через просмотр снимков и скриншотов удалось выяснить что он каким-то своими делами занимается или отдыхает а деньги получает. Пришлось с ним расстаться
Я заведую 4 командами продукт менеджеров и у меня в прямом подчинении 14 человек, всего — 24. Возможно это покажется мало, поэтому еще немного цифр.
В моей зоне ответственности 45 продуктов группы компаний. Для этих 45 продуктов мои команды обеспечивают:
— Бизнес и Технические спецификации на новые функции
— Технические спецификации на повышение быстродействия (у нас это отдельный тип задач)
— Управление бэклогом кастомер дефектов (8000+)
— Пользовательская и админская документация, релиз ноутс
Кстати, вы как считаете — 24 человека для такого скоупа — это много, мало или в самый раз?
На лодке могут быть проблемы с интернетом :)
Реальный кейс из истории компании — один человек решил поехать в кругосветку (ну или что-то подобное) на яхте и работать при этом.
И в общем-то все было хорошо пока он не добрался до Кубы. Там случилась беда с интернетом и чувака уволили, потому что по понятным причинам добраться быстро до интернета у него не получилось.
Не знаю подробностей, это было кажется года три назад, так что я историю слышал из каких-то там 150х уст
Бывает я говорю «я ненавижу компьютеры». Это как раз случается в такие моменты :)
Любое ПО иногда глючит, по умолчанию. В трекере Crossover есть возможность ручного внесения тайм кард, которая используется в том числе как раз для таких случаев.
Конечно просто так беспорядочно вносить ручные тайм карды нельзя, на каждую ручную запись должно быть объяснение — почему и апрув от менеджера. Но в ситуации когда трекер глючит я ни разу не видел чтобы отказывали в ручном времени.
Не совсем так. Точнее совсем не так :)
Существует политика трекинга, в ней в том числе сказано, что допускается несколько «face off» тайм кард в день. Также рекомендуется не отключать трекер если перерыв составляет менее 10 минут, что вполне подходит под ваши «10 перерывов по 5 минут в день».
У меня лично примерно так же с перерывами, я не отключаю трекер и не дорабатываю 4 часа в выходные.
Только я не понял почему 4 часа, ведь 10x5 = 50 минут
Спасибо за Ваш комментарий.
День с переработкой выбран на самом деле по другой причине — разнообразие типа активностей в течение одного дня. А то, что он с переработкой это случайно получилось. И я в стриме так же рассказал немного подробнее.
Работа 40 часов по трекеру это и правда много. По субъективным ощущениям это больше и сложнее чем 40-часовая рабочая неделя в офисе. Потому что в офисе — пришел, попил кофе, потрындел с коллегами, поработал, потом пообедал, погулял итд. Здесь же это должны быть именно рабочие часы, когда ты непосредственно работаешь.
Сначала немного непривычно, особенно в первые пару недель после трудоустройства, но потом привыкаешь и нет ощущения чрезмерной нагрузки.
Да и вообще, работы у нас много и задач вполне хватает на 40 часов, а при желании и на больше.
Человека без подготовки гораздо проще научить писать XSLT-преобразования, чем писать код на любом из языков высокого уровня. Чтобы писать нормальный код надо хорошо знать теорию ООП, паттернов разработки, API живущих рядом модулей итд.
Для написания XSLT всего этого не нужно знать. К тому же, отладка гораздо проще, не надо никаких IDE устанавливать, не надо никаких vcs настраивать, ну и всех остальных разработческих штук.
И все-таки в нашей системе XSLT используется скорее не для кастомизации, а для описания преобразования нашего входного/выходного формата данных к API внешних систем, а они априори различны в нашем случае.
Век живи — век учись ))
Бывает так, что когда решаешь какую-то задачу даже не представляешь во что она трансформируется через год, два, итд.
Так и было в этом случае — сначала надо было сделать-то порядка 100 услуг, но со временем количество возрастало, а сроки уменьшались. И мы следом за спросом/рынком оптимизировали наши инструменты чтобы оставаться конкурентоспособными.
Аналитик программировать по-умолчанию совсем не умеет, но изучить формат взаимодействия внешних сервисов должен уметь.
Универсальные адаптеры, обработчики запроса/ответа, механизмы валидации, заложены в ядре фреймворка. Для настройки внешних запросов аналитику достаточно написать XSLT описывающие преобразование запросов, ответов, и с помощью графического интерфейса настроить маппинг полученных снаружи значений на поля формы.
Что касается локализации — да, это известная головная боль. Пока такие возможности во фреймворк не заложены, то есть он — одноязычный.
Но если добавлять такую фичу, то сначала переработка ядра — локализация набора виджетов, визуальных элементов, добавление новых свойств к объектам. Это работа группы разработки ядра.
Затем донастройка самих форм — заполнение добавленных языковых атрибутов. С этим уже легко справятся аналитики
Согласен, что надо пользоваться готовым если если есть возможность, а не изобретать велосипеды. Но в нашем случае задача была слишком специфичная и существовавшие на тот момент решения нам не подошли.
itur форма — один из элементов функции «электронная государственная услуга». Перевод услуги в электронный вид и есть цель создания в том числе формы.
Наше решение покрывает 2 элемента — экранная форма и настройка части бизнес-процесса, которая должна выполняться на портале госуслуг — заполнение и отправка заявления гражданина на получение услуги. Остальная часть — регистрация, обработка данных, подготовка ответа — выполняется уже в информационной системе ведомства, оказывающего услугу.
И тогда 100-200 технарей это нормально. только к ним ещё надо менеджеров 300+ добавить
Одной из целей создания решения как раз и было минимизировать количество технарей, сохраняя при этом производительность.
Каждый человек, разрабатывающий формы общался напрямую с представителем заказчика и сам потом настраивал все как надо на форме. Это сократило издержки на «сломанный телефон» заказчик -> аналитик -> разработчик
antirek, да инструмент разрабатывался в рамках создания портала gosuslugi.ru, и является одним из его модулей, используемым для создания форм получения государственных услуг.
Насколько часто используются те или иные формы зависит от популярности услуги. Есть услуги по которым более миллиона обращений в месяц, а есть непопулярные — по 2-3 обращения. Но нагрузка на формы это отдельная история, и стоит в стороне от непосредственно разработки услуг.
Готовые решения нам не подошли по нескольким причинам:
— на момент начала проекта (2012 г) таких решений было не так много
— большинство из них платные и не opensource
— мы знали, что потребуются очень кастомные вещи (типа виджета ввода трудовой деятельности при подаче заявления на загранпаспорт), а затраты на кастомизацию доступных на тот момент решений были сравнимы с написанием своего решения
— «зоопарк» технологий в чужих решениях. Мы ограничились стеком технологий, который уже был использован при разработке личного кабинета и каталога услуг портала gosuslugi.ru
Самое главное, из-за чего решили делать самостоятельно — помимо создания/исполнения самих форм, фреймворк должен был соответствовать ряду бизнес-процессов, принятых для построении систем электронного правительства. Например, как я писал в статье — формирование XML определенного формата, подписание электронной подписью, взаимодействие с внешними системами через СМЭВ и так далее. Ни одно существующее решение out-of-the-box нельзя без доработок встроить в эти бизнес-процессы, а доработки = затраты, сопоставимые с разработкой своего.
Объясню на примере формы записи ко врачу www.awesomescreenshot.com/image/432244/b6860bea12e58cdc6a1df5b25747fa0b www.gosuslugi.ru/service/10000020298/-10000000603
Сложность этой услуги заключается в том, что в зависимости от введенных пользователем данных выполняются запросы во ИС Минздрава и запрашиваются списки значений для других полей. Вроде бы ничего сложного, но по задумке ни одного разработчика не должно участвовать в создании услуги, и все эти взаимодействия должен настроить аналитик.
Какое из доступных решений позволяет это сделать? Либо никакое либо мы плохо искали.
Мы же смогли все эти настройки вынести в пользовательский интерфейс и с такого рода задачами справляются аналитики за пол-дня.
Что касается opensource — нет, пока не планируем. Возможно в будущем
А на счет оффлайновой офисной работы (опять же, если она тебе по душе) потери фокуса выливаются в 10-14 часов «нахождения» в офисе. Потому что дела-то тоже надо делать, не только фокус терять на разговорах и прогулках.
Если ты работаешь исключительно «за деньги» и без особого удовольствия от самого процесса, то да, 8 честных часов это сложновато, да и не нужно — есть куча других мест где можно работать <=4 и получать норм деньги
Например был у меня один человек который хитрыми способами читил трекер, я заметил значительную просадку в его производительности и через просмотр снимков и скриншотов удалось выяснить что он каким-то своими делами занимается или отдыхает а деньги получает. Пришлось с ним расстаться
В моей зоне ответственности 45 продуктов группы компаний. Для этих 45 продуктов мои команды обеспечивают:
— Бизнес и Технические спецификации на новые функции
— Технические спецификации на повышение быстродействия (у нас это отдельный тип задач)
— Управление бэклогом кастомер дефектов (8000+)
— Пользовательская и админская документация, релиз ноутс
Кстати, вы как считаете — 24 человека для такого скоупа — это много, мало или в самый раз?
Реальный кейс из истории компании — один человек решил поехать в кругосветку (ну или что-то подобное) на яхте и работать при этом.
И в общем-то все было хорошо пока он не добрался до Кубы. Там случилась беда с интернетом и чувака уволили, потому что по понятным причинам добраться быстро до интернета у него не получилось.
Не знаю подробностей, это было кажется года три назад, так что я историю слышал из каких-то там 150х уст
Любое ПО иногда глючит, по умолчанию. В трекере Crossover есть возможность ручного внесения тайм кард, которая используется в том числе как раз для таких случаев.
Конечно просто так беспорядочно вносить ручные тайм карды нельзя, на каждую ручную запись должно быть объяснение — почему и апрув от менеджера. Но в ситуации когда трекер глючит я ни разу не видел чтобы отказывали в ручном времени.
Существует политика трекинга, в ней в том числе сказано, что допускается несколько «face off» тайм кард в день. Также рекомендуется не отключать трекер если перерыв составляет менее 10 минут, что вполне подходит под ваши «10 перерывов по 5 минут в день».
У меня лично примерно так же с перерывами, я не отключаю трекер и не дорабатываю 4 часа в выходные.
Только я не понял почему 4 часа, ведь 10x5 = 50 минут
День с переработкой выбран на самом деле по другой причине — разнообразие типа активностей в течение одного дня. А то, что он с переработкой это случайно получилось. И я в стриме так же рассказал немного подробнее.
Работа 40 часов по трекеру это и правда много. По субъективным ощущениям это больше и сложнее чем 40-часовая рабочая неделя в офисе. Потому что в офисе — пришел, попил кофе, потрындел с коллегами, поработал, потом пообедал, погулял итд. Здесь же это должны быть именно рабочие часы, когда ты непосредственно работаешь.
Сначала немного непривычно, особенно в первые пару недель после трудоустройства, но потом привыкаешь и нет ощущения чрезмерной нагрузки.
Да и вообще, работы у нас много и задач вполне хватает на 40 часов, а при желании и на больше.
Для написания XSLT всего этого не нужно знать. К тому же, отладка гораздо проще, не надо никаких IDE устанавливать, не надо никаких vcs настраивать, ну и всех остальных разработческих штук.
И все-таки в нашей системе XSLT используется скорее не для кастомизации, а для описания преобразования нашего входного/выходного формата данных к API внешних систем, а они априори различны в нашем случае.
Бывает так, что когда решаешь какую-то задачу даже не представляешь во что она трансформируется через год, два, итд.
Так и было в этом случае — сначала надо было сделать-то порядка 100 услуг, но со временем количество возрастало, а сроки уменьшались. И мы следом за спросом/рынком оптимизировали наши инструменты чтобы оставаться конкурентоспособными.
Универсальные адаптеры, обработчики запроса/ответа, механизмы валидации, заложены в ядре фреймворка. Для настройки внешних запросов аналитику достаточно написать XSLT описывающие преобразование запросов, ответов, и с помощью графического интерфейса настроить маппинг полученных снаружи значений на поля формы.
Что касается локализации — да, это известная головная боль. Пока такие возможности во фреймворк не заложены, то есть он — одноязычный.
Но если добавлять такую фичу, то сначала переработка ядра — локализация набора виджетов, визуальных элементов, добавление новых свойств к объектам. Это работа группы разработки ядра.
Затем донастройка самих форм — заполнение добавленных языковых атрибутов. С этим уже легко справятся аналитики
Нет, с разработчиками этих систем не знаком
Наше решение покрывает 2 элемента — экранная форма и настройка части бизнес-процесса, которая должна выполняться на портале госуслуг — заполнение и отправка заявления гражданина на получение услуги. Остальная часть — регистрация, обработка данных, подготовка ответа — выполняется уже в информационной системе ведомства, оказывающего услугу.
Одной из целей создания решения как раз и было минимизировать количество технарей, сохраняя при этом производительность.
Каждый человек, разрабатывающий формы общался напрямую с представителем заказчика и сам потом настраивал все как надо на форме. Это сократило издержки на «сломанный телефон» заказчик -> аналитик -> разработчик
Насколько часто используются те или иные формы зависит от популярности услуги. Есть услуги по которым более миллиона обращений в месяц, а есть непопулярные — по 2-3 обращения. Но нагрузка на формы это отдельная история, и стоит в стороне от непосредственно разработки услуг.
Готовые решения нам не подошли по нескольким причинам:
— на момент начала проекта (2012 г) таких решений было не так много
— большинство из них платные и не opensource
— мы знали, что потребуются очень кастомные вещи (типа виджета ввода трудовой деятельности при подаче заявления на загранпаспорт), а затраты на кастомизацию доступных на тот момент решений были сравнимы с написанием своего решения
— «зоопарк» технологий в чужих решениях. Мы ограничились стеком технологий, который уже был использован при разработке личного кабинета и каталога услуг портала gosuslugi.ru
Самое главное, из-за чего решили делать самостоятельно — помимо создания/исполнения самих форм, фреймворк должен был соответствовать ряду бизнес-процессов, принятых для построении систем электронного правительства. Например, как я писал в статье — формирование XML определенного формата, подписание электронной подписью, взаимодействие с внешними системами через СМЭВ и так далее. Ни одно существующее решение out-of-the-box нельзя без доработок встроить в эти бизнес-процессы, а доработки = затраты, сопоставимые с разработкой своего.
Объясню на примере формы записи ко врачу
www.awesomescreenshot.com/image/432244/b6860bea12e58cdc6a1df5b25747fa0b
www.gosuslugi.ru/service/10000020298/-10000000603
Сложность этой услуги заключается в том, что в зависимости от введенных пользователем данных выполняются запросы во ИС Минздрава и запрашиваются списки значений для других полей. Вроде бы ничего сложного, но по задумке ни одного разработчика не должно участвовать в создании услуги, и все эти взаимодействия должен настроить аналитик.
Какое из доступных решений позволяет это сделать? Либо никакое либо мы плохо искали.
Мы же смогли все эти настройки вынести в пользовательский интерфейс и с такого рода задачами справляются аналитики за пол-дня.
Что касается opensource — нет, пока не планируем. Возможно в будущем