2 of October - MS Stage Free Online conference: .NET, MS SQL, MS Azure, Cosmos DB. REGISTER
×Закрыть
CTO/IT Project Manager/Technical Product Manager
  • Авто для семьи с тремя детьми

    В 2012 у меня стоял выбор между C4 Grand Picasso и Chevrolet Orlando. Немного жалею что взял второй (француза нужно было ждать долго под заказ), но в целом 7 мест в таком формате себя оправдали. Правда с двумя автокресоами мы не ездили, и у нас двое детей (возили ещё и родителей). Так что советую этот вариант, или кроссовер, но классом повыше (из конкурентов BMW X5). Мелкий кроссовер == мало места для ног ребёнка в автокресле, и мало багажника.

  • Машина для нищеброда айтишника

  • Готовитесь к GDPR?

    Меня вот интересует более узкий вопрос (по долгу службы) — что будет с рекламными сервисами?
    A точнее с рекламой на мобильных устройствах, где у пользователя есть IDFA/GAID (а это по GDPR — персональные данные). И эти персональные данные для таргетированной рекламы используют одновременно по 3-5, а иногда и десятки разных компаний в речении нескольких секунд пока мобильное приложение ожидает ответа на рекламный запрос.
    Как в этом сценарии можно умудриться получить явное согласие пользователя на участие всех этих компаний в обработке и хранении его персональных данных?
    Да, в отдельных случаях с прямыми рекламодателями разработчик приложения может один раз в неделю/месяц спросить у пользователя, согласен ли он видеть персонализированную рекламу от конкретных компаний.

    И в случае Facebook, с относительно закрытой рекламной экосистемой, есть возможность показать все детали в профиле пользователя. Но даже у них возникает проблема разделенной ответственности для «lead ads»:

    In the case of lead ads, both Facebook and the business are data controllers, thus, both parties are responsible for ensuring compliance by providing notice and establishing a legal basis for processing the data provided by a user. The lead ads product offers advertisers the ability to link to their privacy policies and terms related to the collection and use of user data.

    Тот же Google не дает ответа на обработку клика по рекламе сторонними сервисами:

    Google’s vendor controls for publishers are not designed to cover click- tracking technologies.

    Но самое интересное будет происходить у игроков поменьше.
    Например AppsFlyer — рекламная платформа для трекинга и отчетности — неявно заявляет что IP и IDFA/GAID являются не личными данными, а просто «данными из SDK»:

    The data collected by the SDK includes information such as IP address, User agent, platform, SDK version, anonymous User ID, time stamp Developer Key, application version, device identifiers such as: IDFA (Identifier For Advertisers), Android ID (Android device), Google Advertiser ID, device model, manufacture, OS version, in-app events, and network status (WiFi/3G)
    ...
    By «Personal Information» we mean any information that can be directly associated with a specific person or entity such as a name, address, telephone number, e-mail address, or information about activities directly linked to such person.

    Их прямой конкурент Kochava для своей DMP указывает что в ней нет EU Citizens:

    The Kochava Collective audience marketplace does not include data derived from EU data subjects.

    Как этого можно добиться, если пользователь из EU может годами ездить по всему миру?

    AppLovin — крупная рекламная платформа — вообще определяет себя как Data Processor, перенося ответственность за сбор и хранение информации о согласии пользователя на своих клиентов:

    2.1 The Parties agree that with regard to the Processing of Personal Data, User is the Data Controller and AppLovin is the Data Processor.

    Хотя у них есть Audience Targeting — DMP. А значит они собирают и обрабатывают персональные данные от издателей, и должны получать на это явное согласие пользователей.

    Пока что подобных вопросов становится все больше. И крупные игроки дают на них только частичные ответы.

    Будет жарко!

    Поддержал: Gennady Dogaev
  • Как развивается карьера Project Manager в IT: масштаб от S до XL

    Когда вакансию Project Manager открывают в небольшой компании, или для нового отдела, обычно ищут первого IT-ориентированного руководителя. И делают это либо владельцы/руководители компании, либо HR/рекрутеры компании, либо рекрутеры из агентства.
    Собственно вопрос теоретически может быть задан им (что я и делал на собеседованиях).

    В моем ответе на DOU этот вопрос — скорее итог нашего с вами описания пути развития руководителя в IT компании.

    Возможно DOU станет первым ресурсом, на котором эта тема станет причиной переименовать

    Посада: Project manager

    на что-то более точное.

    И я смогу описывать свою специальность более точно, не отвечая на дополнительные вопросы, и попадая в результаты поиска :)

  • Как развивается карьера Project Manager в IT: масштаб от S до XL

    Здравствуйте.

    Из личного опыта могу добавить что в компаниях созданных под продукт, Масштаб S будет очень похожим. Но также будет доступ к менеджменту той же компании, который принимает решения о бюджете, объеме работ, и берет на себя управление рисками проекта. Владельцы и менеджмент компании будут выполнять роль «клиента» для менеджера масштаба S.

    Масштабы M и L будут сильно отличаться от описанных в статье, поскольку даже очень большой и успешный продукт может развиваться и поддерживаться сравнительно небольшим IT-отделом. Фокус может постепенно смещаться из разработки продукта в поддержку пользователей и небольшие проекты по интеграции с партнерами. А проектная организация работы совмещаться с процессной деятельностью.

    Если продукт ориентирован на массовый рынок, то у руководителя команды/отдела разработки масштаба M/L появятся новые «типы» клиентов в лице отделов Sales, Marketing, Customer Support, Accounting etc. А также несколько «коллективных» клиентов в лице разных групп пользователей.
    Владельцы компании перестанут выступать в роли «клиента», и появится понятие «интересы компании», которое раньше было равно «интересам клиента». Менеджмент компании, в зависимости от условий контракта, может как выступать на 100% представителем владельцев, так и представлять еще один тип «внутреннего» клиента.
    В то же время менеджмент компании будут выполнять роль ... менеджера масштабов M/L в вопросах контрактов, P&L и стратегического видения. А руководитель команды/отдела разработки будет заниматься бюджетом (своего отдела), рисками, приоритетами, ресурсами, развитием команды и ... контрактами и P&L меньшего масштаба. Также, могут сформироваться в отдельные команды/отделы IT/DevOps и Technical Support.

    Если продукт ориентирован на внутренние потребности компании, то фокус и области ответственности руководителя IT-отдела будут еще сильнее отличаться от того, что описано в статье. С ростом IT-отдела и/или бизнеса все может как меняться каждые пол-года, так и не меняться много лет подряд. Разработку могут приостановить, отменить из-за замены на уже готовое внешнее решение, или передать в аутсорсинг другой компании. При подобных изменениях руководитель может встать перед выбором — покинуть компанию (развивая экспертизу руководителя проектов в IT), либо полностью изменить свой профиль и позицию (применяя и развивая экспертизу в конкретном виде бизнеса).

    Масштаб XL в компаниях ориентированных на продукт (или к этому этапу — уже линейку продуктов и несколько видов бизнеса) обычно слабо связан с IT даже для позиций CIO/CTO. И полный переход на этот уровень в реалиях Украины — скорее исключение, чем типичный путь развития. Типичный путь — это сразу с позиции менеджера/владельца стартовать свой бизнес, или перейти в другую компанию на этапе стартапа или создания IT-отдела. А это уже совсем другая история :)

    Как видим, отличия от описанной модели развития — значительные. И позиция Project Manager, в ее классическом понимании, также не на 100% отражает суть работы руководителя среднего и высшего звена в таких компаниях.
    Так кого же ищут рекрутеры в Украине, открывая вакансии Project Manager? :)

  • Практика на практике, или 7 секретов входа в IT

    Именно за «человек должен уметь что-то делать» в нашей сфере и платят «800-2000 зеленых в перспективе».

    Так вот, для таких людей очень важна возможность практики в компании — в первое время бесплатно, в дальнейшем, пускай с небольшой зарплатой, но с перспективой.

    Я не могу оценивать весь рынок труда. Как и в первом ответе, скажу по опыту из своей практики найма. «Первое время бесплатно» — это только с точки зрения новичка Trainee. По факту же получается, что есть две ситуации — потенциально прибыльная, и потенциально убыточная.
    Варианты ситуации:
    a) нанимаем Junior Engineer с опытом работы. Платим «условно» $100 в месяц первые 3 месяца + ему помогают разобраться в проекте 2-3 человека в сумме 2-4 часа в день. Допустим «условно» еще $200 мы платим им не за разработку, а за обучение новичка. Итого $900 за 3 месяца, и почти 100% шанс получить полноценного участника команды.
    б) нанимаем Trainee без опыта работы. Не платим первые 3 месяца + ему помогают разобраться в проекте 2-3 человека в сумме 4-6 часов в день. Платим им допустим $300 за обучение новичка. Итого $900 за три месяца, но шанс получить полноценного участника команды — 50%. А значит нужно взять несколько таких Trainee, и бюджет вырастает в разы.

    Надеюсь, не нужно объяснять какая из ситуаций потенциально убыточная?

    Поддержал: Yarik Genza
  • Дмитрий Думанский. Держим 20 млрд реквестов в месяц

    Спасибо! Был отличный доклад и очень полезная сессия Q&A.

  • Рейтинг языков программирования № 5, январь 2014

    Демография
    Руслан,

    Предлагаю в следующий раз делить не по десятилетиям, а по возрастным группам — ru.wikipedia.org/....B4.D0.BE.D0.B2

    У тебя в группах < 20 и 20-30 сразу три возрастные группы, причем 3-я неполная. Потому в 20-30 настолько больше, чем в остальных. Перегруппируй, и будет более ровная картинка :)

    Поддержал: Vladyslav Kurmaz
  • Requirements management tools

    Только это не должна быть Jira, потому что требования — это одно, а tasks — это другое.

    Вариант А: Два проекта в Jira с разными workflow. Для работы с требованиями я что-то такое видел уже готовое.

    Вариант Б: Один проект в Jira, но для требований свои типы задач и свой (упрощенный) workflow. Достаточно совпадения начала и окончания workflow для успешного отслеживания прогресса.

    Вариант В: Wiki — движков много, я бы рекомендовал Confluence, MediaWiki. Но разбивать на релизы и указывать важность прийдется вручную, каким-то велосипедным способом. Не очень поддерживаю этот вариант поскольку в wiki лучше хранить документы без статуса, и как можно более свежие, а старые удалять/прятать в архив.

  • Саботажники в наших рядах. Вычислить и обезвредить

    И все хором начнут «прямо» говорить друг другу кто и почему им не нравится — сколько они выдержат?
    Хвали публично, ругай лично. Думаю, персональное замечание по скайпу или в переговорке/на перекуре, не добавит шума в опенспейсе. :)
  • Когда вы проводите standup?

    Не проводим.

    Поддержал: Artem Komisarenko
  • Карьера в IT: должность Project Manager

    В целом статья все правдиво описывает. Плюс-минус во многих проектах на 5+ человек в команде разработки так и есть
    Пару замечаний с моей колокольни:
    1.

    проектирование
    Это задача всей проектной команды, а не PM-a. Области PM-a в данной деятельности — определение рисков, определение и распределение ресурсов, администрирование процесса проектирования (митинги-шмитинги, документы-мокументы...)
    Собственно ниже так и написано:
    1. Проектирование нового продукта или какого-либо нового функционала. На этом этапе PM организовывает митинг с техническим архитектором и разработчиками, оглашает задачи, которые им предстоит решить. В результате команда определяет путь, по которому пойдёт разработка.

    2.

    контролировать качество
    Это задача QA. Задача PM-a — организовать этот контроль, создать и результативно применить роль QA, но не выполнять ее.

    3.

    Обязанности PM’а:
    ...
    — (1) разбивка продукта на компоненты и (2) раздача их исполнителям;
    (1) — это обязанность команды разработки. Обязанность PM-а — обеспечить процесс/процедуру для этого, и контролировать результат.
    (2) — зависит от подхода к работе над оперативным списком задач (backlog, iteration, queue). При push подходе — обязанность PM-а, при pull подходе — обязанность команды разработки.

    4.

    ...
    — (3) определение приоритетности задач;
    — (4) общение с заказчиком, управление его ожиданиями;
    — (5) предоставление заказчику отчетности о ходе выполнения задач и проекта в целом;
    — (6) презентация заказчику готовых решений, демо-версий, прототипов;
    ...
    Обязанности из этого набора сильно зависят от специфики проекта (предметная область, масштаб, зрелость продукта,...). Чаще всего в моих проектах эти обязанности выполняет Product Manager/Product Owner. По (3) и (4) — самостоятельно, по (5) — с участием PM-а, а по (6) c участием команды разработки.

    5. Если "типичный рабочий день"=="день посреди sprint-а" (процесс разработки == Scrum), то следующее — верно:

    — Планирование очереди задач на текущий день;
    — Проверка выполненной работы команд за прошедший день;
    — Проведение стендапа с командой;

    Иначе — скорее исключение, чем типичный случай. Для конкретики приведу факты из моего текущего проекта:
    — задачи запланированы и распределены заранее;
    — проверку выполняют: QA (на Testing environment) + разработчики (per-review, unit testing) + Release Manager (перед релизом и hotfix-ом) + Product Manager/Reporter (на Staging environment)
    — нет никаких ежедневных совещаний (stand-up, daily scrum, «летучка» etc.), а есть JIRA, где все видно и без совещаний.
    В «типичный» день PM-а я бы добавил «выполнение контроля рисков», поскольку именно за это PM (с технической экспертизой) отвечает всегда.

    6.

    пришли в профессию точно так же — с ин.яза, без опыта, но с каким-то интуитивным пониманием диджитал процессов.
    Это точно было интервью с PM-ом из разработки ПО? «Digital» — это термин из немного другой области — издательской, рекламной, медийной.

    7.

    включая топ-менеджмент: CTO, CEO, CIO, COO.
    CIO я бы из этого списка исключил, если мы говорим о PM-е в проектах разработки ПО. Chief Information Officer — это цель вертикального развития для системных администраторов и консультантов по внедрению систем автоматизации.

    Спасибо автору за статью, а DOU за обсуждение. Будет на что сослаться :-)

  • Как у вас устроено управление проектами? Вопрос к программистам и ПМ

    John Doe,
    Если бы я не хотел отвечать (или помогать автору темы), я бы не писал такой длинный комментарий 3 дня назад. На ваш вопрос об оценке трудозатрат у меня попросту нет ответа, и я не могу его предоставить, даже если очень захочу. Я ведь не знаю ни бизнес-моделей компании, ни проектов, ни команды, ни договоренностей с клиентами. Это все знает владелец (управляющий) компании, и мой совет адресован именно ему, а не вам, или сообществу в целом.
    Мой совет — типичный план выхода из кризиса для небольшой проектно-ориентированой компании. Он основан на следующих предположениях:
    — автор темы является владельцем/управляющим,
    — в компании есть кризис по ряду проектов,
    — в компании не ведется управление рисками,
    — у компании есть запас прочности (несколько стабильных проектов, финансовый запас) для внесения планируемых изменений в бизнес-модель.
    Также, мой совет основывается на предыдущем опыте участия в подобных изменениях (которые проводил не я, кстати) в IT-компаниях. Отсюда и совет производить изменения за 1 квартал.
    На выполнения работ в пунктах 2, 3, 4 (и частично в 1 и 6) у меня, как PM, уходило от 2 до 5 недель, при этом я вел работу над оставшимися проектами. Но ситуация сильно отличалась от ситуации автора темы — меньше проектов, больше людей в командах разработки, другой состав команд.
    Надеюсь, я ответил на просьбу.

    Поддержал: Евгений Козлов
  • Как у вас устроено управление проектами? Вопрос к программистам и ПМ

    9. Если через 3 повторения так ничего и не получилось — закрыть бизнес.
    Затрат (времени и денег) должно хватить на это + на поддержание проектов лояльных клиентов в период перехода + на возврат средств не лояльным клиентам.
    Сценарий выхода из бизнеса без долгов я, в формате DOU, рассчитывать не готов. :) Все остальные детали, и их «самая важность» зависят от того кол-ва денег и времени, которыми располагает владелец компании.
    Вопрос в том, что можно сделать очень и очень многое
    Я с этим не могу согласиться. Сделать можно ровно столько (или меньше), сколько есть на это средств. Или сколько владелец готов выделить, если есть и другие более важные проблемы, требующие решения в тот же период.

    John Doe:

    полагаю что у ТС не так много времени и средств на это.
    ...
    Можете оценить затраты на то, что предложили?
    Андрей Барилко:
    я конечно понимаю что это игра, и заказчик всегда желает получить в 100 больше, чем за то что он заплатил, выжав все соки со всех

    Вы часом не заказчик Андрея? :)

  • Как у вас устроено управление проектами? Вопрос к программистам и ПМ

    Зубатому PM-у нужно платить.
    :)
  • Как у вас устроено управление проектами? Вопрос к программистам и ПМ

    Зубатому PM-у нужно платить. И у него должно быть понимание, и внутреннее убеждение того, что его работа в итоге принесет пользу всем 4 сторонам (клиенту, владельцу бизнеса, команде разработки, ему самому).
    Боюсь, столкнувшись с такой бизнес-моделью, которую описал автор темы, я бы отказался по двум из этих двух критериям.

    Мой совет ТС — постройте немедленно (вот прям сегодня) план выхода из кризиса вида:
    1. Завершить (как можно быстрее) деятельность по текущим проектам.
    2. Сделать оценку (Pros/Cons) работающей бизнес-модели, определить риски, принять стратегию их избежания/снижения влияния/устранения последствий.
    3. Описать случаи (и условия их возникновения), при которых теряли/не могли получить прибыль.
    4. Разработать менее рисковую, более прибыльную бизнес-модель (нанять эксперта, если своими силами не выйдет). Важно базироваться на фактах, а не мнениях, и принимать решения+сроки выполнения, а не «общую стратегию + предполагаемую ситуацию».
    5. Начать новые проекты по новой бизнес-модели (если повезет, то с теми же клиентами).
    6. Оценить результаты, сравнивая то что было (Pros/Cons + $) с тем что стало (Pros/Cons + $). Период сравнения рекомендую выбрать в 1 квартал, с разбивкой по месяцу (не календарному, а финансовому). По проектам в вашем случае я бы сравнение/разбивку не делал.
    7. Если результат понравился, и денег стало больше, закрепить успех многократным повторением, каждый раз контролировать Pros/Cons + $, стараться не вносить больших изменений.
    8. Если результат провальный, повторить с пункта 1, либо 3 (в зависимости от рисков, которые сработали).
    9. Если через 3 повторения так ничего и не получилось — закрыть бизнес.

    Пункт 0 — сообщить своим сотрудникам о предстоящих изменениях и их причинах, (и возможных следствиях — по желанию). Если этого не сделать, все толковые разработчики уйдут между шагами 1 и 5.

  • Какую компанию выбрать?

    Наличие возможности не всегда приводит к использованию возможности.
    P.S. Тролль останется голодным.

  • Какую компанию выбрать?

    У каждого свои критерии удачи.

  • Какую компанию выбрать?

    Уточнение: позиция не девелопера а тестировщика...
    Это практически ничего не меняет.
  • Практика на практике, или 7 секретов входа в IT

    В вакансии все требования четко прописаны. Но дело не в этом.
    Даже не читая требования, по названию вакансии человек может себя сопоставить, либо не сопоставить с ней. В нашем случае Senior кандидаты сопоставляют себя боле-менее верно, а вот Junior — как я написал.
    Видимо, обилие на нашем рынке труда вакансий с тайтлом Junior, но без опыта работы, вводит людей в заблуждение по поводу типичных требований к такой вакансии.

← Сtrl 1234567 Ctrl →