Solution Architect в Customertimes Ukraine
  • Проект Refactor.UA: рефакторимо Україну разом

    Тут без PoC не разобраться:
    1. Собираем по одному представителю от любой ИТ компании, который будет внутренней точкой коммуникации.
    2. Внутри каждой компании собираем две группы. Участие в любой из групп на добровольной основе. Первая — будет гарантированно отчислять 10% каждый месяц. Здесь конечно надо какой-то договор, чтобы максимально приблизиться к оригинальной идее. Вторая группа будет перечислять столько сколько и когда считает нужным.
    3. Разворачивается (берётся готовая, новая, дописывается) краудфандинговая платформа, которая должна проверить работоспособность самого механизма фонда: список идей, голосование, разрешение конфликтов, отчётность, выбор подрядчиков, контроль выполнения и пр.
    4. Запуск 1 октября 2016 на 6 месяцев.
    5. Выбираются три цели, которые можно закончить в данный период:
    A — глобальная, обладающая вау эффектом, для продвижения данной идеи внутри ИТ и вне
    B — задача средней тяжести, должна показать как работать с внешними подрядчиками и большими суммами, тоесть показать рефакторинг.
    C — легковесная задача, на случай провала A и B, плюс может быть ориентиром для определения team velocity.

  • Проект Refactor.UA: рефакторимо Україну разом

    Пару обобщающих мыслей после прочтения комментариев здесь и обсуждения с коллегами:
    Pros:
    1. Идея создать новую «бизнес-модель» на базе синергетики profit и non-profit. Успех здесь зависит от того насколько больше проблем данное решение снимет, чем породит. В принципе она коллиниарна тому, куда движутся такие компании как Tesla и Valve с точки зрения своих миссий.
    2. Построение бренда «социально-ориентированная компания». На каком-то этапе бренд сам начинает «зарабатывать» — это, возможно позволит, снизить издержки на HR и people management, а также позволит привлекать клиентов.
    ...
    Cons:
    1. Фактически «целевая аудитория» — innovators и early adopters, так как в такой среде, нужно брать на себя обязанность выплачивать дополнительно 10% и принимать риски того, что все может прогореть. 16% от ~100К распределённых по все стране. Такие представители ИТ наиболее подвижны и могут служить дополнительным риском.
    2. Возможность постронения эффективной системы коллективного фонда, где решения об инвестициях принимаются сообща большим кол-вом участиков — ещё один ключевой вопрос.
    3. Концепция базируется на «разности температур» зарплат и налогов, выплачиваемых по схеме СПД. Работающая по данному приципу компания может служить стартовой точкой отмены схем СПД для ИТ. Мы все видели как молниеносно протянули Генерального прокурора. Это может просто разрушить текущую структуру по предоставлению ИТ услуг из Украины.
    4. Ключевым мотиватором работать в компании такого типа, будут более высокие ступеньки пирамиды Маслоу. Любая нестабильность и каждый человек, и айтишник с том числе, будет стараться защищать нижние слои, дополнительные 10% налогов этому не будут способствовать. Говорю это как человек, прошедший волну 2008 года, когда компании, работающий в области gamedev(entertainment), схлопывались очень быстро, 60 компаний в Киеве за 3 месяца. Текучка кадров может быть даже выше.
    5. Использование базы в виде аутсорс\аутстаф модели. Прибыль сотрудника === убыток компании. В данной схеме даже в принципе не возможен экспоненциальный рост как при продуктовой модели. Это задаёт жёсткую планку объёма потенциальных средств для социальных проектов, которые можно будет собрать и как следствие круг проблем, которые можно будет решить в стране с их помощью.
    Нет камней — нет стройки, нет стройки — нет дворца, нет дворца — нет дворца )))
    ...
    В любом случае надо делать PoC.

  • Проект Refactor.UA: рефакторимо Україну разом

    Открою Вам тайну, под 5 и 10 нет никакой экономической базы. Так просто легче впаривать и стричь взносы.
    5 пальцев на одной руке, 10 пальцев на двух руках.
    И теперь Вам с этим жить )))

    Поддержали: anonymous, Gramm
  • Software: Bears, Bulls & Swaps

    Как минимум это доказывает тот факт, что RUP загнулся
    Согласен, работать по RUP или Waterfall могут себе позволить только очень небольшое кол-во доменов.
    Но любой опытный PM все равно должен владеть всем инструментарием, чтобы уметь двигаться по вашем графику и умело переключаться по вашему графику.
    Это можно вынести как сухой остаток.
  • Проект Refactor.UA: рефакторимо Україну разом

    Изначальное купировние в рамках одной ИТ компании слишком рисковано, так же как “зашивание” процентной ставки.
    ...
    С коллегой прорабатывали идею краудфандинга в масштабе Украины — Громадські Інвестори.
    ...
    Стратегическая цель:
    закрепить на законодательном уровне ПРАВО, не ОБЯЗАННОСТЬ, самостоятельно распределять 80% своих налогов.
    ...
    Тактическая цель:
    Платформа, которая позволит проводить прямые инвестиции в различные социальные\гос проекты: отремонтировать часть дороги, переселить семью из зоны АТО, прямая помощь семьям погибших\переселенцев, поменять окна в школе и т.д..
    На первых этапах, это будут такие же перечисления как сейчас многие делают волонтёрам.
    Деньги потраченные на этом этапе должны будут вычтены из налогов участника в будущем.
    ...
    Это не фонд, компании выполняющие подряды должны получать прибыль.
    Прозрачность бухгалтерии.
    Очень сродни Прозорро и Моя репутация

  • Software: Bears, Bulls & Swaps

    Ок ) «Добрым словом и пистолетом вы можете добиться гораздо большего, чем одним только добрым словом».
    ...
    Предположим, Вы на законодельном уровне объявили проактивную борьбу с техническим долгом.
    1. Необходимо создать дополнительное поле в вашем менеджере задач (TechnicalDebt)
    2. В процессе очередного планирования:
    * команда решает добавить в спринт, задачу явно прикруточную, чтобы пройти демо, выкатить обновление и пр: захаркодить IP адрес, список языков, игнорировать временную зону и т.д. Такая задача создаётся со значением поля TechnicalDebt = 1. Тут же, необходимо создать задачу, которая должна будет компенсировать данное решение. Она так же заносится в трекер со значением TechnicalDebt = −1
    * разработчики убедили команду что нужно отрефакторить какую-то часть кода, внедрить новый фрейворк, переписать несколько методов: создаём задачи с TechnicalDebt = −1. Но тут же выясняем как это сможет ускорить разработку и создаёт для этого будущие задачи с TechnicalDebt = 1. Например если мы внедрим enterprise service bus, то на интеграцию с социальными сетями мы будем тратить на порядок меньше времени: создаём задачу подключить 20 сервисов через oauth2 за 2 дня (facebook, twitter, linkedin, uber, ...)
    ...
    Что можно ожидать. Здесь влияние такое же как и при внедрении юнит-тестирования: чем больше кода покрыто тестами, тем меньше комитов, ломающих сборки, тем меньше тратится времени на локализацию и правку ошибок. В данном случае технический долго не будет накапливаться и разговоры от том, чтобы переписат всё с нуля, будут звучать значительно реже, как и желание пускать проект на самотек.
    ...
    PM — будет понимать, что за любую прикрутку нужно будеть расплачиваться и должен будет держать в фокусе критичные для заказчика аспекты и не дотягивать до конца спринта и\или релиза с их решением.
    Любое предожение в духе: давайте перепишем этот говно-код, должно будет обосновано, конкретным списком фич, которые буду улучшены в разрезе полезного функционала приложения\сервиса.

  • Software: Bears, Bulls & Swaps

    Согласен во всём, кроме участка
    Да, здесь классическая ловушка использования устоявшихся терминов.
    Я старался использовать термины «Agile» и «Waterfall», для обозначения ситуаций, когда есть перекос или в сторону процесса или результата.
    Если в PoC и MVP более или менее понятно, то схема выше должна была выглядеть так
    PoC -> MVP -> «Agile» -> «Waterfall»
    ...
    Я бы, в принципе, рассматривал waterfall — если мы понимаем под этим словом именно кондовый водопад со строго последовательными фазами — как некий вырожденный случай, работающий исключительно на мелких проектах наподобие запуска инфо-сайтов путем прикручивания и допиливания темы к какой-нибудь CMS.
    Вот тут не соглашусь, по причине участия в разработке авиа симулятора для Antonov AN-148.
    Waterfall был единственно возможным подходом, по причине вовлечённости большого количества подрядчиков. Да, после утверждения интерфейсов, каждый из подрядчиков мог изменить процесс разработки. Но с уровня конечного продукта — водопад был единстенно приемлимым решением.
    Так что строго последовательные фазы применяются и на больших проектах.
    Поддержал: Yuri Pyvovarenko
  • Software: Bears, Bulls & Swaps

    в яку PM-ам дожмуть розробники, і яку PM ткне розробникам явно
    В таком случае любая методика не будет работать ), из-под палки в ИТ мало что работает
    ...
    Один из моментов, который я хочу донести в данной статье: выиграть можно только принимая во внимания обе составляеющие процесса разработки.
    ...
    Приняв спорное решение перед демо, ПМ должен выделить временной бюджет для возвращения технического долга.
    Потратив ощутимое время на проектирование, Tech lead должен форсировать разработку полезного для заказчика функционала.
    ...
    In My Simple World )
    Поддержали: Yuri Pyvovarenko, Sergey Sorokin
  • Software: Bears, Bulls & Swaps

    Спасибо, моё ощущение границ между PoC и MVP аналогичное.
    Если обощить, то чем больше мы уделяем времени архитектуре, тем больше мы смещаемся вправо
    PoC -> MVP -> Agile -> Waterfall.

    Поддержали: Yuri Pyvovarenko, Anna Opilat
  • Software: Bears, Bulls & Swaps

    Спасибо Олександр, Вы услышали то, что я хотел сказать.

    Немного добавлю от себя.
    Здесь Результат более абстрактное понятие чем даже story points.
    Я бы измерял его в Epic/Story — в том, что действительно важно заказчику: залогиниться, скачать файл, построить график и т.д.

    Поддержал: Yuri Pyvovarenko
  • Software: Bears, Bulls & Swaps

    Как я упоминал, слишком накладно, требовать от разработчиков делать такую оценку для каждой задачи «руками».

    Як
    Это может быть дополнительное поле для задачи в Jira.
    коли
    Можно делать при создании задачи, можно во время её закрытия. Главное чтобы подобные задачи были обязательно промаркированы.
    як часто
    Для каждой задачи, которая имеет явные признаки «перекоса» в ту или иную сторону.
    Поддержал: Yuri Pyvovarenko
  • Software: Bears, Bulls & Swaps

    Я специально не специализировал на графике, что же такое точки 1 и 2.
    Это может быть весь проект или, как В Вашем примере, граница одного спринта.
    Суть не поменяется, главное в конце интервала стараться полностью возвращать накопленный технический долг.

    Поддержал: Yuri Pyvovarenko
  • Software: Bears, Bulls & Swaps

    Яка в автора головна думка — неясно.
    Как с помощью дополнительной метрии стремиться к созданию своевременного, качественного и «долгоживущего» ПО.
    Поддержал: Yuri Pyvovarenko
  • Software: Bears, Bulls & Swaps

    Согласен, что между PoC и MVP достаточно тонкая грань.
    ...

    o_OА хто заважає реалізовувати прототип прямо в рамках продукту?
    Потому что, вероятность того, что данная идея будет принята в разработку очень низка. Я не случайно упомянул R&D/Incubator команды, для которых создание PoC основная задача.
    ...
    А хто заважає використовувати `dummy data` (`mocks`) для того, щоб не просто зробити прототип, а ще й майже повнофункціональний прототип?
    Никто. Чем больше ресурсов вы выделяете для реализации внутренней структуры продукта, тем больше вы смещаетесь в область MVP и полноценной разработки продукта.
    ...
    Для PoC я просто забью в код exit(file_get_contents($fname))
    Для MVP скорее всего я подключу какую-нибудь mocks/fakes библиотеку.
    Вопрос тольков в том что “time-to-market” для первого варианты выше, за счёт экономии на дизайне и внутренней структуре продукта.
    ...
    Здесь нет чёткой границы между черным и белым.
  • Как в FB увидеть все мероприятия в городе?

    вы потом удивляетесь, что сообщество на доу считают недружелюбным?
    у нас тут своя атмосфера )))

    ...
    www.theverge.com/...earby-events-location-app
    www.facebook.com/...ion/?id=10201749749651827
    ...
    Yes, Sign in with FB login at world.timeout.com and click “Go to location” within the map. Then type in the city you want to see events in
    ...
    Через фб кажется пока никак, через апи точно можно и более сложные запросы делать.

  • Как в FB увидеть все мероприятия в городе?

    lmgtfy.com/...search events by location
    первая ссылка
    stackoverflow.com/...k-events-by-location-city
    там есть вопросы\ответы и не через API

    Поддержал: Олексій Пєніє
  • Уровни абстракций — ключ к пониманию архитектурных изысков ПО

    Как правильно заметили, проблема больше философская, но тем не менее интересная, чтобы рассмотреть её в разрезе разработки ПО.
    ...
    In my simple world, было бы полезно дополнительно рассмотреть как данные подходы и умозаключения реализуются в области инструментальных средств — языков программирования, тоесть ближе к телу )
    ...
    * ортогональный интерфейс, мы же создаём абстракции не просто так, а чтобы потом наделить их поведением (или выделять их на основе поведения)
    * наследование, композиция, агрегация. извечная борьба, советы применения на реальных примерах.
    * интерфейс, класс, объект — тут работать и работать, я даже не могу предложить с какой стороны тут подходить к решению )
    ...

    «пишите, Шура»
  • Как выбрать хороший сыр — советы эксперта Дарьи Ивашкевич

    Денег вроде хватает, не пробовал ничего из списка.
    Со мной что-то не так?

  • Тебе втирают дичь про IT

    dou.ua/add-post
    ссылка с главной страницы под секцией статей
    Всі матеріали Прислати статтю RSS

    Поддержал: Taras Voloshenko
  • Работа в IT для свитчеров из других специальностей

    Запомните этот твит — DevOps на горизонте в пять лет станет главным элементом в разработке ПО

← Сtrl 123456...23 Ctrl →