Эта культура закладывалась и проповедовалась где-то с 2001 отцами-основателями. По ходу роста, культивировалась дополнительно через других людей, разные вики, общение и тд. — ну и отцы не спят до сих пор, также иногда есть и возникают проблемы — что греха таить. В частности, уже как пару лет нанят отдельный «игил*-коач», как ласково называем тренера.
* не имеет отношения к запрещенной организации — просто по корявому произношению Agile:-)
Ага, благодарю за уточнение. У нас стендапы и обертки в виде Scrum — дело частое, но добровольное — каждая команда решает сама как лучше организовать работу. Вот приверженность принципам Agile и особенно следование XP уже не опция.
Ясно, спасибо. Тоже гибко в зависимости от трайба (следуем Spotify модели) и по структуре похоже: также нет отдельных тестеров + техписатели еще под боком, все варятся в одном инфопотоке. В большинстве, обязанности PO по сути выполнял тех-тимлид помимо другой работы сам или с помощью коллег (например, часть PMM задач делегируется евангелистам или маркетинг отделу — без командной работы никуда и тут). Экспериментируем с full-time PO/PM, чтобы ни на что другое не отвлекались.
Спасибо, что в очередной раз рассказываете про ваш PMM. До этого смотрел ваши посты типа habrahabr.ru/company/JetBrains/blog/294994. Мне особенно интересно, т.к. сам занимаюсь 5+ лет занимаюсь уже подобным для крупного продукта (проблемы все очень близки, типа переключения контекста, тяжесть совмещения — решаю большим делегированием обязанностей в команду или по принципу www.mountaingoatsoftware.com/blog/the-chief-product-owner-on-large-agile-projects последнее время), только называется у нас это «Product Owner/Manager»…
Также как и в комментарии выше, ваш список обязанностей «Если в целом, я» в очередной раз навел меня на мысль, что Marketing в названии вашей должности лишнее или не основное… Я примерно занимаюсь тем же самым и по целям и по конкретным примерам деятельности, разве что за исключением конференций. Большое вовлечение в разработку (также потому, что у нас клиенты разработчики, как и у вас), общение с пользователями, поддержка. Больше перечислено тут: agiletrail.com/2011/11/29/37-tasks-for-a-product-owner%E2%80%99s-job
Вопрос: у вас есть отдельные Product Owner еще или расскажите поподробнее про устройство/работу продуктовых команд изнутри (помимо маркетинга-евангелизма). Спасибо заранее.
Спасибо за статью, Алексей (актуальная тема и в нашей компании). Интересно узнать больше о вашей системе:
1. Насколько подробны ваши общие описания уровней или примеры их проявлений по 3м ценностям компании?
2. Уточняете ли вы отдельно ожидания по ролям (разработчик, дизайнер, супорт, тестировщик, техписатель и др.)?
3. Как сотрудники в среднем оценивают ясность и полезность этих критериев?
Для пояснения того, приведу пример другой известной компании:
https://labs.spotify.com/2016/02/15/spotify-technology-career-steps/ (см. Expectations for each Step).
Еще раз благодарю за то, что решили поделиться опытом.
Павел, сложности есть всегда, и многое зависит от самих людей. По мне основной секрет успеха — это прививка ценности на уровне компании — люди должны понимать где и для чего они работают (опять же в «Put everyone on the front lines» главе из Rework от 37 signals неплохо расписано). Помимо передачи «кастомер-боли»/сценариев использования разработчикам, у нас само руководство, например, читает каждый отзыв в «Uninstall Feedback» письмах, налажена передача информации напрямую либо через мыл-листы и др. каналы, чтобы все были в курсе интересных вещей/серьезных проблем и могли формировать понимание, принимать решения. OKR опять же — тоже неплохой фреймворк в помощь для лучшего следования ценностям компании/трайба.
К разработчикам опять, есть такое неплохое летучее выражение: «Пиши код так, как будто в дальнейшем его будет поддерживать сумасшедший психопат-убийца, который знает, где ты живешь». На практике его пробовали реализовывать для некоторых особо важных новых фич даже путем технической поддержки самими разработчиками на протяжении нескольких месяцев после релиза. Так авторы еще лучше могут «прочувствовать» слабые места и оперативно выпускать обновления.
Удачи!
Спасибо за развернутые ответы, Павел!
По п.4 смотрю у меня там опечатки, простите. Имел ввиду возможные потери пользовательского фидбека (как хорошего, так и плохого) или недонесение его до разработчиков за счет прослойки между клиентов. Уточнял это отдельно, так как мы с этим сталкивались в некоторых командах и эта проблема также описывается в сообществе. Хорошо, что у вас все хорошо:-) и п.5 лишний раз это подтверждает.
Мои ответы на ваши вопросы:
1. Да, линии по сути просто сортируют работу на день: все что можно простое — отвечаем сразу, сложные кейсы просто требуют доп. исследований и времени.
2. Да, сложностей куча, начиная от элементарного владения деловым английским языком и заканчивая чисто мотивационными «не барское это дело» или «я пишу код, а донести у вас все равно лучше получится», а также желанием соблюсти баланс между супортом и разработкой (фичи писать и тесты поднимать тоже ведь надо). В компании у нас огромное внимание уделяется сервису клиентов, и поэтому одним из принципов является «поддержка клиентов — это ответственность ВСЕЙ команды». Поэтому считаю немаловажным, чтобы разработчики и остальные понимали эту ценность на уровне подкорки. Когда будет понимание, тогда и не будет отношения к процессу поддержки как к повинности. Конечно, как писал выше, также необходим базовый тренинг aka «неделя в супорте», который длится у все по разному в зависимости от исходных данных. Во время него разработчик работает в паре с опытным супортистом и делает обычный разбор линий, пишет сам ответы, получает корректировки по ходу дела и знакомится со всеми остальными секретами данного дела. Дальше плотный контроль потихоньку ослабевает. Если все хорошо, то разработчик идет уже сам в бой и со временем присмотр вообще становится не нужен. Некоторым ребятам вообще очень нравится отвечать тикеты так как приятно все таки общаться с живыми пользователями твоей фичи, получать благодарности, что даже просят иногда «подкиньте посупортить, а то давно не было»:-) — так что это вполне может быть дополнительной мотивацией к работе, тем более полезно менять сферу деятельности. Есть также вообще уникальные команды, где поддержку оказывают целиком дежурные разработчики (как писали выше в коментах), но это скорее исключение. В среднем по больнице, привлекать разработчиков мы стараемся только по реальной необходимости, такой как перегрузы или праздники (по договоренности/желанию разработчики могут выйти в праздники вместо коллег супортистов). Для этого координатор группы супорта продукта в начале дня (чтобы ребята могли лучше спланировать свой день и не переключаться лишний раз) выделяет тикеты на спец линию Developers Queue или «девку» — сей процесс мы даже шутливо называем «разогрев девки»:-)
Так как английский язык очень важен для нашего бизнеса (не только для супорта, но и тупо метод в классе нормально назвать, сделать ревию новой статьи в документации или понять о чем говорили на вебинаре с маркетингом), компания всячески мотивирует сотрудников на улучшение этого навыка (это даже упоминается в оценке уровней) и создает условия для его изучения (компенсации или курсы на базе офиса, причем супорту курсы вообще бесплатно и за счет рабочего времени). В своей команде я лично всегда ставлю поднятие уровня языка на ревию уровней молодым или проблемным ребятам. И это вроде действует — после осознания многие стали ходить на курсы/наняли репетиторов и прокачивают этот навык сами. Дай бог скоро совсем не будет переменных «needRepit» и шуток про «Минаков-стайл»:-)
Конечно, для ответов на тикеты для всех в компании есть специально обученные знатоки языка aka «корректоры» (местные и нативные), которые помогают с грамматикой, стилями и правильными коннотациями, перед тем как ответ уйдет клиенту.
Вроде все из основного — почти на статью получилось… Спрашивайте, если что интересует еще!
Спасибо за статью, Павел – было очень интересно узнать о вашем опыте, так как уже давно занят в данной области — мы правда продаем и обслуживаем инструменты/компоненты для других разработчиков бизнес приложений. Хотел бы задать несколько вопросов:
1. Расскажите, сколько в среднем инцидентов (всего, простых L1 и сложных L2) отвечает рядовой сотрудник супорта и Т2 агент, если это не секретная информация?
2. Как у вас распределяются задачи в работу из очередей (новые и реактивированные инциденты)? В частности, имеет ли каждый супортер всегда в разработке в любой момент времени только одну задачу, которую потом оставляет на себе (AssignedTo)? Берет ли он следующую из общего пула только когда закончит с предыдущей или возможна ситуация, когда на одного сотрудника приходится несколько задач сразу, так как он с ними уже сильно и много разбирался до последней реактивации (ну т.е. личная ответственность vs групповая)?
3. Интересно, возможно ли в вашей системе прогнозирование доступности ресурсов «на будущее», т.е. предсказание ждущим клиентам в очередях типа «При текущей загрузке специалистов вам ответят примерно через 1ч.30», если в вашем бизнесе такое вообще требуется.
4. Как у вас происходит передача запросов и проблем клиентов к разработчикам и другим членам команды? В частности, нет ли с таким T2 подходом проблем с утаиванием/потерей важной информации до тех, кто написал исходный код продукта?
5. Расскажите, пожалуйста, какой еще проактивной работой помимо улучшения качества базы знаний, документации, самого продукта занимаются ваши сотрудники техподдержки.
В заключение, хотелось бы поделиться опытом нашей компании (live chat я брать не буду, пока только расскажу кратко про online help desk с тикетами или почтой). У нас в 2016 году есть те же L1 и L2, но на них практически работают одни и те же сотрудники техподдержки (aka support developers), которые находятся физически рядом с ответственными разработчиками и др. членами команды. Например, мой текущий трайб XAF и в нем есть сквады WinForms, ASP.NET, Mobile, Core, Security, Analytics, которые имеют разработчиков, супортеров, техписателей, дизайнеров (последние два шарятся на трайб ввиду дефицита данных ресурсов). Отдельных тестеров или отдела QA у нас нет — автоматическое юнит, функциональное и ручное тестирование производится силами всей команды. Специалист супорта в трайбе у нас универсален и может ответить на любой вопрос по продукту/направлению, но в то же время он также старается больше фокусироваться на теме своего сквада, например, Core (эта специализация касается как поддержки так и разработки/тестирования новых фич). В тоже время есть небольшое число очень опытных и мега универсальных спецов. Ответы стараемся давать в течение бизнес дня или в большинстве случаев раньше (<24ч), основной язык общения — английский (по-русски тоже можно пообщаться в приватных тикетах при большой необходимости), есть вторая смена (15.00-00.00) для охвата западного побережья, priority line для некоторых подписок типа Universal, эскалация на руководство. Как и думаю везде, стараемся чтобы на L1 не залеживалось тикетов старше нескольких часов (1-2 в идеальном мире), на L2 попадают сложные кейсы, которые нельзя/быстро сразу ответить (например, какой-то сложный проект для долгой отладки) либо с полной инфой после всех уточнений, чтобы любому можно было сразу взять без усилий и начать разбираться. Например, если прислали проект, надо убедиться, что он собирается и запускается, есть шаги и др. необходимые данные. Супорт должен хорошо разбираться в поддерживаемом продукте с технической стороны, отлаживать проекты клиентов, грамотно и вежливо передавать им решения и др. информацию, искать и оформлять баги со всеми шагами (все баги должны предварительно заверяться вместе с разработчиками), анализировать код и запросы клиентов, быть передатчиком клиентской боли и запросов в команду, взаимодействовать со всеми коллегами, чтобы планировать будущие релизы и улучшать сам продукт, базу знаний и онлайн документацию. «Идеальный» супортер у нас — эдакий чтец, жнец и на дуде игрец, разве что баги сам не фиксит и фичи с тестами не пишет (хотя есть и такие исключения). Конечно, создание такого «швейцарского ножа» требует долгой и серьезной подготовки, но плюсы очевидны и также легче сохранять мотивацию таких специалистов на высоком уровне за счет большого разнообразия задач. Конечно, это все было бы невозможно или сложно, если бы под боком не было друзей-разработчиков, которые вместе с нами слушают customer pain/suggestions (мы стараемся следовать принципу Put everyone on the front lines как в Rework от 37 signals и доводить эту инфу до авторов напрямую), планируют изменения и помогают в сложных случаях или делятся знаниями. Иногда, в случае больших завалов или на праздники, сами разработчики напрямую привлекаются для ответов на тикеты (конечно, каждый предварительно проходит тренинг, чтобы соответствовать стандартам техподдержки компании по вежливости, грамотности, стилю и др.). Вкратце вроде все описал:-)
P.S.
Пользуемся вашим продуктом для некоторых marketing задач, спасибо!
Спасибо за ваш отзыв. Грид всегда ищет по вхождению в контент или теги. Для булевских колонок там в качестве тегов слова checked/unchecked (или их локализованные аналоги). Собственно, если искать по фрагменту, входящему в оба слова («che») то оба варианта и покажутся в результате.
Для более тонкого поиска можно применять разные модификаторы, например "-un" — покажет все что НЕ unchecked — т.е. то что checked. Также хочется отметить, что для булевских колонок кажется намного удобнее и быстрее применять не поиск, а фильтрацию по значению через column filter dropdown (пару кликов вместо набора текста). Наконец, если текущее поведение не нравится, то всегда можно отключить поиск для булевских колонок в опциях грида. Надеюсь данная информация будет полезной.
… и саппорт вместо ответов на вопросы будет просить продлить подписку.
Хотел уточнить, что сейчас техподдержка по старой версии продукта, которую вы купили однажды, оказывается в обычном режиме, даже если ваша подписка истекла — без помощи с нашей стороны вы точно не останетесь.
По новой версии тоже можно свободно задавать вопросы в рамках пробного периода для этой самой новой версии.
Да, я упоминал его в п.3.
Плюс в 13й студии они избавились от модальности этого окна. Эх, еще бы сделали побольше опций, чтобы можно было сильнее урезать результаты поиска (файл, тип, метод и другие, как в кодераше), а не только по @, тогда и правда задумаюсь о переходе. Вообще приятно видеть, как Visual Studio улучшается последнее время… чую вполне можем увидеть какие-то из перечисленных выше «киллфич» в Visual Studio 201NEXT:-)
В начале поста писал про разработчиков, сидящих на Visual Studio 2010 или более ранних версиях, которые не такие продвинутые как последние. Во-вторых, даже если студия умеет что-то, то инструмент может делать это более изящно, хотя не всегда (например, я использую стандартный Shift+F12 (Find All References) вместо кодерашевского диалога).
Ну и, конечно же, студия с CodeRush тоже умеет много всего, что тут не описано.
Когда лоб-в-лоб столкнулся с New SecuritySystem, предполагал, что она работает несколько иначе (теперь это относится ещё и к контролю доступа member'ов): объект можно изменить, но контроль осуществляется по состоянию объекта, хранящегося в БД. В текущей же реализации стоит изменить какое-то поле, например типа bool, которое не соответствует критерию доступа на запись (до изменения соответствовало), то всё, запись запрещена.
Мы здесь полностью копируем поведение системы безопасности Windows. Представьте, что у вас запрещен доступ на запись в каталог файлов с именем autorun.exe. Логично будет предположить, что нельзя нарушить это правило путем переименования существующего файла в этом каталоге.
По WPF клиенту, не планировали пока. Сугубо мое личное мнение: для конечного пользователя типичное бизнес приложение будет выглядеть также, да и делать будет то же самое, только возможно будет чуть медленнее + выше требованиями к железу, что может быть уже чувствительным для бизнеса.
Но есть кое-какие планы освежить Веб (не факт, что ASP.NET MVC) или подружить ксаф с PhoneJS. Конечно для этого мы еще хотим усилить серверную часть, так как без хорошего сервера (security, workflow, audit, validation, etc.) сейчас никуда (говорю со взглядом на мобильные клиенты).
Все проверки системы безопасности в сценарии с отдельным сервером происходили и происходят на стороне сервера. Вот тут можно почитать больше.
Хочу заметить также, что для различных нужд заказчиков и удобства развертывания есть еще и «клиентский» режим работы системы безопасности aka Client-Side Security — Integrated Mode. Например, это удобно в сценарии с ASP.NET приложением (оно уже само по сути клиент-серверное) ну или когда простой сценарий и нет таких требований по безопасности, чтобы не возиться с отдельным сервером и ящиком для него.
По вашему описанию я понял как раз, что вы и трогали этот Integrated Mode.
Про view или хранимки, мое мнение, что в таких сценариях вам вообще ксаф не нужен и лучше все сделать без него. Ну или по-другому: вы не поимеете всех его «плюшек» с таким подходом. Все таки это ORM-based фреймворк, где подразумевается оперирование бизнес сущностями, представленными CLR объектами, а не таблицами и др. объектами базы напрямую через SQL. Точки-то расширения для вас мы всегда найдем, но боюсь получится опять «через жопу к звездам»:-)
Резюмируя, мы не особо «затачивали» фреймворк под этот (неосновной) сценарий. Если очень сильно нужно, то подлезть можно, но я бы не рекомендовал. Спасибо за отзыв, как бы там ни было, будем держать в голове ваше пожелание.
>>Никто не мешает хакнуть соединение с сервером БД.
Мм… так есть же у ксаф свой сервер, на котором собственно и происходят проверки безопасности. Т.е. клиентское ксаф приложение соединено не напрямую с базой, а с сервером и клиент не получает вообще нефильтрованные данные. Это опция как раз подходит для таких серьезных сценариев. Единственное, что этот сценарий с сервером еще в процессе шлифовки, чтобы обеспечить более лучшую производительность, а так все должно работать.
>>В целом мы XAF юзали (и вы о нас даж писали)
Дмитрий, к сожалению, слету не припомню вас по одному имени. Можете кинуть название компании в личку или прямо тут?
>>а еще есть у XPO проблемки с oracle odp.net провайдером (текут сессии, нет нормальной поддержки транзакций)… потом отпишу в суппорт.
Будем очень признательны за подробности в тикете в www.devexpress.com/sc
* не имеет отношения к запрещенной организации — просто по корявому произношению Agile:-)
Также как и в комментарии выше, ваш список обязанностей «Если в целом, я» в очередной раз навел меня на мысль, что Marketing в названии вашей должности лишнее или не основное… Я примерно занимаюсь тем же самым и по целям и по конкретным примерам деятельности, разве что за исключением конференций. Большое вовлечение в разработку (также потому, что у нас клиенты разработчики, как и у вас), общение с пользователями, поддержка. Больше перечислено тут:
agiletrail.com/2011/11/29/37-tasks-for-a-product-owner%E2%80%99s-job
Вопрос: у вас есть отдельные Product Owner еще или расскажите поподробнее про устройство/работу продуктовых команд изнутри (помимо маркетинга-евангелизма). Спасибо заранее.
1. Насколько подробны ваши общие описания уровней или примеры их проявлений по 3м ценностям компании?
2. Уточняете ли вы отдельно ожидания по ролям (разработчик, дизайнер, супорт, тестировщик, техписатель и др.)?
3. Как сотрудники в среднем оценивают ясность и полезность этих критериев?
Для пояснения того, приведу пример другой известной компании:
https://labs.spotify.com/2016/02/15/spotify-technology-career-steps/ (см. Expectations for each Step).
Еще раз благодарю за то, что решили поделиться опытом.
К разработчикам опять, есть такое неплохое летучее выражение: «Пиши код так, как будто в дальнейшем его будет поддерживать сумасшедший психопат-убийца, который знает, где ты живешь». На практике его пробовали реализовывать для некоторых особо важных новых фич даже путем технической поддержки самими разработчиками на протяжении нескольких месяцев после релиза. Так авторы еще лучше могут «прочувствовать» слабые места и оперативно выпускать обновления.
Удачи!
По п.4 смотрю у меня там опечатки, простите. Имел ввиду возможные потери пользовательского фидбека (как хорошего, так и плохого) или недонесение его до разработчиков за счет прослойки между клиентов. Уточнял это отдельно, так как мы с этим сталкивались в некоторых командах и эта проблема также описывается в сообществе. Хорошо, что у вас все хорошо:-) и п.5 лишний раз это подтверждает.
Мои ответы на ваши вопросы:
1. Да, линии по сути просто сортируют работу на день: все что можно простое — отвечаем сразу, сложные кейсы просто требуют доп. исследований и времени.
2. Да, сложностей куча, начиная от элементарного владения деловым английским языком и заканчивая чисто мотивационными «не барское это дело» или «я пишу код, а донести у вас все равно лучше получится», а также желанием соблюсти баланс между супортом и разработкой (фичи писать и тесты поднимать тоже ведь надо). В компании у нас огромное внимание уделяется сервису клиентов, и поэтому одним из принципов является «поддержка клиентов — это ответственность ВСЕЙ команды». Поэтому считаю немаловажным, чтобы разработчики и остальные понимали эту ценность на уровне подкорки. Когда будет понимание, тогда и не будет отношения к процессу поддержки как к повинности. Конечно, как писал выше, также необходим базовый тренинг aka «неделя в супорте», который длится у все по разному в зависимости от исходных данных. Во время него разработчик работает в паре с опытным супортистом и делает обычный разбор линий, пишет сам ответы, получает корректировки по ходу дела и знакомится со всеми остальными секретами данного дела. Дальше плотный контроль потихоньку ослабевает. Если все хорошо, то разработчик идет уже сам в бой и со временем присмотр вообще становится не нужен. Некоторым ребятам вообще очень нравится отвечать тикеты так как приятно все таки общаться с живыми пользователями твоей фичи, получать благодарности, что даже просят иногда «подкиньте посупортить, а то давно не было»:-) — так что это вполне может быть дополнительной мотивацией к работе, тем более полезно менять сферу деятельности. Есть также вообще уникальные команды, где поддержку оказывают целиком дежурные разработчики (как писали выше в коментах), но это скорее исключение. В среднем по больнице, привлекать разработчиков мы стараемся только по реальной необходимости, такой как перегрузы или праздники (по договоренности/желанию разработчики могут выйти в праздники вместо коллег супортистов). Для этого координатор группы супорта продукта в начале дня (чтобы ребята могли лучше спланировать свой день и не переключаться лишний раз) выделяет тикеты на спец линию Developers Queue или «девку» — сей процесс мы даже шутливо называем «разогрев девки»:-)
Так как английский язык очень важен для нашего бизнеса (не только для супорта, но и тупо метод в классе нормально назвать, сделать ревию новой статьи в документации или понять о чем говорили на вебинаре с маркетингом), компания всячески мотивирует сотрудников на улучшение этого навыка (это даже упоминается в оценке уровней) и создает условия для его изучения (компенсации или курсы на базе офиса, причем супорту курсы вообще бесплатно и за счет рабочего времени). В своей команде я лично всегда ставлю поднятие уровня языка на ревию уровней молодым или проблемным ребятам. И это вроде действует — после осознания многие стали ходить на курсы/наняли репетиторов и прокачивают этот навык сами. Дай бог скоро совсем не будет переменных «needRepit» и шуток про «Минаков-стайл»:-)
Конечно, для ответов на тикеты для всех в компании есть специально обученные знатоки языка aka «корректоры» (местные и нативные), которые помогают с грамматикой, стилями и правильными коннотациями, перед тем как ответ уйдет клиенту.
Вроде все из основного — почти на статью получилось… Спрашивайте, если что интересует еще!
1. Расскажите, сколько в среднем инцидентов (всего, простых L1 и сложных L2) отвечает рядовой сотрудник супорта и Т2 агент, если это не секретная информация?
2. Как у вас распределяются задачи в работу из очередей (новые и реактивированные инциденты)? В частности, имеет ли каждый супортер всегда в разработке в любой момент времени только одну задачу, которую потом оставляет на себе (AssignedTo)? Берет ли он следующую из общего пула только когда закончит с предыдущей или возможна ситуация, когда на одного сотрудника приходится несколько задач сразу, так как он с ними уже сильно и много разбирался до последней реактивации (ну т.е. личная ответственность vs групповая)?
3. Интересно, возможно ли в вашей системе прогнозирование доступности ресурсов «на будущее», т.е. предсказание ждущим клиентам в очередях типа «При текущей загрузке специалистов вам ответят примерно через 1ч.30», если в вашем бизнесе такое вообще требуется.
4. Как у вас происходит передача запросов и проблем клиентов к разработчикам и другим членам команды? В частности, нет ли с таким T2 подходом проблем с утаиванием/потерей важной информации до тех, кто написал исходный код продукта?
5. Расскажите, пожалуйста, какой еще проактивной работой помимо улучшения качества базы знаний, документации, самого продукта занимаются ваши сотрудники техподдержки.
В заключение, хотелось бы поделиться опытом нашей компании (live chat я брать не буду, пока только расскажу кратко про online help desk с тикетами или почтой). У нас в 2016 году есть те же L1 и L2, но на них практически работают одни и те же сотрудники техподдержки (aka support developers), которые находятся физически рядом с ответственными разработчиками и др. членами команды. Например, мой текущий трайб XAF и в нем есть сквады WinForms, ASP.NET, Mobile, Core, Security, Analytics, которые имеют разработчиков, супортеров, техписателей, дизайнеров (последние два шарятся на трайб ввиду дефицита данных ресурсов). Отдельных тестеров или отдела QA у нас нет — автоматическое юнит, функциональное и ручное тестирование производится силами всей команды. Специалист супорта в трайбе у нас универсален и может ответить на любой вопрос по продукту/направлению, но в то же время он также старается больше фокусироваться на теме своего сквада, например, Core (эта специализация касается как поддержки так и разработки/тестирования новых фич). В тоже время есть небольшое число очень опытных и мега универсальных спецов. Ответы стараемся давать в течение бизнес дня или в большинстве случаев раньше (<24ч), основной язык общения — английский (по-русски тоже можно пообщаться в приватных тикетах при большой необходимости), есть вторая смена (15.00-00.00) для охвата западного побережья, priority line для некоторых подписок типа Universal, эскалация на руководство. Как и думаю везде, стараемся чтобы на L1 не залеживалось тикетов старше нескольких часов (1-2 в идеальном мире), на L2 попадают сложные кейсы, которые нельзя/быстро сразу ответить (например, какой-то сложный проект для долгой отладки) либо с полной инфой после всех уточнений, чтобы любому можно было сразу взять без усилий и начать разбираться. Например, если прислали проект, надо убедиться, что он собирается и запускается, есть шаги и др. необходимые данные. Супорт должен хорошо разбираться в поддерживаемом продукте с технической стороны, отлаживать проекты клиентов, грамотно и вежливо передавать им решения и др. информацию, искать и оформлять баги со всеми шагами (все баги должны предварительно заверяться вместе с разработчиками), анализировать код и запросы клиентов, быть передатчиком клиентской боли и запросов в команду, взаимодействовать со всеми коллегами, чтобы планировать будущие релизы и улучшать сам продукт, базу знаний и онлайн документацию. «Идеальный» супортер у нас — эдакий чтец, жнец и на дуде игрец, разве что баги сам не фиксит и фичи с тестами не пишет (хотя есть и такие исключения). Конечно, создание такого «швейцарского ножа» требует долгой и серьезной подготовки, но плюсы очевидны и также легче сохранять мотивацию таких специалистов на высоком уровне за счет большого разнообразия задач. Конечно, это все было бы невозможно или сложно, если бы под боком не было друзей-разработчиков, которые вместе с нами слушают customer pain/suggestions (мы стараемся следовать принципу Put everyone on the front lines как в Rework от 37 signals и доводить эту инфу до авторов напрямую), планируют изменения и помогают в сложных случаях или делятся знаниями. Иногда, в случае больших завалов или на праздники, сами разработчики напрямую привлекаются для ответов на тикеты (конечно, каждый предварительно проходит тренинг, чтобы соответствовать стандартам техподдержки компании по вежливости, грамотности, стилю и др.). Вкратце вроде все описал:-)
P.S.
Пользуемся вашим продуктом для некоторых marketing задач, спасибо!
Для более тонкого поиска можно применять разные модификаторы, например "-un" — покажет все что НЕ unchecked — т.е. то что checked. Также хочется отметить, что для булевских колонок кажется намного удобнее и быстрее применять не поиск, а фильтрацию по значению через column filter dropdown (пару кликов вместо набора текста). Наконец, если текущее поведение не нравится, то всегда можно отключить поиск для булевских колонок в опциях грида. Надеюсь данная информация будет полезной.
Хотел уточнить, что сейчас техподдержка по старой версии продукта, которую вы купили однажды, оказывается в обычном режиме, даже если ваша подписка истекла — без помощи с нашей стороны вы точно не останетесь.
По новой версии тоже можно свободно задавать вопросы в рамках пробного периода для этой самой новой версии.
Плюс в 13й студии они избавились от модальности этого окна. Эх, еще бы сделали побольше опций, чтобы можно было сильнее урезать результаты поиска (файл, тип, метод и другие, как в кодераше), а не только по @, тогда и правда задумаюсь о переходе. Вообще приятно видеть, как Visual Studio улучшается последнее время… чую вполне можем увидеть какие-то из перечисленных выше «киллфич» в Visual Studio 201NEXT:-)
Ну и, конечно же, студия с CodeRush тоже умеет много всего, что тут не описано.
Мы здесь полностью копируем поведение системы безопасности Windows. Представьте, что у вас запрещен доступ на запись в каталог файлов с именем autorun.exe. Логично будет предположить, что нельзя нарушить это правило путем переименования существующего файла в этом каталоге.
Но есть кое-какие планы освежить Веб (не факт, что ASP.NET MVC) или подружить ксаф с PhoneJS. Конечно для этого мы еще хотим усилить серверную часть, так как без хорошего сервера (security, workflow, audit, validation, etc.) сейчас никуда (говорю со взглядом на мобильные клиенты).
Хочу заметить также, что для различных нужд заказчиков и удобства развертывания есть еще и «клиентский» режим работы системы безопасности aka Client-Side Security — Integrated Mode. Например, это удобно в сценарии с ASP.NET приложением (оно уже само по сути клиент-серверное) ну или когда простой сценарий и нет таких требований по безопасности, чтобы не возиться с отдельным сервером и ящиком для него.
По вашему описанию я понял как раз, что вы и трогали этот Integrated Mode.
Про view или хранимки, мое мнение, что в таких сценариях вам вообще ксаф не нужен и лучше все сделать без него. Ну или по-другому: вы не поимеете всех его «плюшек» с таким подходом. Все таки это ORM-based фреймворк, где подразумевается оперирование бизнес сущностями, представленными CLR объектами, а не таблицами и др. объектами базы напрямую через SQL. Точки-то расширения для вас мы всегда найдем, но боюсь получится опять «через жопу к звездам»:-)
Резюмируя, мы не особо «затачивали» фреймворк под этот (неосновной) сценарий. Если очень сильно нужно, то подлезть можно, но я бы не рекомендовал. Спасибо за отзыв, как бы там ни было, будем держать в голове ваше пожелание.
Мм… так есть же у ксаф свой сервер, на котором собственно и происходят проверки безопасности. Т.е. клиентское ксаф приложение соединено не напрямую с базой, а с сервером и клиент не получает вообще нефильтрованные данные. Это опция как раз подходит для таких серьезных сценариев. Единственное, что этот сценарий с сервером еще в процессе шлифовки, чтобы обеспечить более лучшую производительность, а так все должно работать.
>>В целом мы XAF юзали (и вы о нас даж писали)
Дмитрий, к сожалению, слету не припомню вас по одному имени. Можете кинуть название компании в личку или прямо тут?
>>а еще есть у XPO проблемки с oracle odp.net провайдером (текут сессии, нет нормальной поддержки транзакций)… потом отпишу в суппорт.
Будем очень признательны за подробности в тикете в www.devexpress.com/sc