CTO в Iterah
  • Тени незабытых айтишников. Или сколько потеряет государство, если айтишники уйдут в тень?

    Так нужно опустить налоги для всех чтоб не было схем и другие отрасли могли также развиваться как и IT. На сегодня схемы ФОП используют для вывода денег без уплаты массы налогов. просто прикрыть схему и заставить всех платить вместе 5% аж 50% — не выйдет, уйдут даже не в тень, а в «чернь» или закроются совсем.
    Договариваться с государством не о чем. И вообще не правильная постановка вопроса. IT сектор приносит кучу денег Украине и занимает 9% ее общего экспорта именно благодаря тому что ему не «помогают развиваться». Это государство должно идти сейчас к IT сектору и договариваться с ним чтоб он хотя бы не снижал темпы развития

  • Тени незабытых айтишников. Или сколько потеряет государство, если айтишники уйдут в тень?

    Да ладно Грузия — поляки бы как обрадовались, Кипр, Турция — да кто угодно был бы счастлив такому. Только одна страна в Европе выживает из себя трудоспособных, квалифицированных и обеспеченных людей — все остальные страны давно за это конкурируют.

  • Тени незабытых айтишников. Или сколько потеряет государство, если айтишники уйдут в тень?

    Сначала неуплату налогов надо доказать, а это в век криптоваты крайне сложно, темболее в Украине. В худшем случае отсюда можно прекрасно уехать в десятки более привлекательных для айтишников стран и сожалеть особо будет не о чем.

    Підтримали: igor shaula, Maxim Deyneka
  • Зачем возвращаться: плюсы жизни в Украине

    Похвально конечно. Дай Бог чтоб этотого запала хвтило хотя бы лет на 5. В моей команде был когдато анти-имигрант и как я ему сразу и предсказал — вернулся в Геманию в течении первого года анти-имиграции.
    А касательно Дании и Скандинавии где я много бывал по работе, то — таки-да, ты там в гостях у богатых родственников. совсем другая атмосфера в США например и примеров возвращения оттуда я не встречал.

  • Как оценить часы на разработку

    Полностью согласен с автором. Причем практически с каждым пунктом. Согласен также с теми кто высказывается за реалистичные эстимейты вместо того чтоб умышленно занижать их чтоб не потерять клиента но потом провалить прект. По опыту, стоимость проекта всегда выше тех естимейтов что дают разработчки. Можно взять любой продукт и посчитать затраченные трдочасы и разделив их на кол-во фич увидеть что на каждую из них приходиться гораздо больше чем можно было ее проэстимировать. Также люди часто забывают( а разработчики и не должны об этом думать) что есть планинги, ретро, демо и др митинги. Т е нужно учитывать не только идеальный день но и «идеальный спринт», ну и конечно же будут баги и на них нужно закладывать буфер. В итоге тогда мы имеем шанс получить реалистичные эстимейты просто для того чтоб быть в них более уверенными. Просто умножить на 2 или 3 это не вариант т к цель не прикрыть свой зад а научится работать четко попадая в свои обещания. У нас команда за год не провалила ни один спринт. Но до того как клиент начал нам доверять и перестал все пересчитывать и торгогваться в эстимейтах, пришлось конечно же авторитет заслужить. Однако в целом конечно же очень сложно иногда обяснить клиенту из чего состоит задача и посему по факту она в среднем стоит в 2 раза больше чем эстимация развработчика.

    Підтримав: Mossberg
  • Украинский рынок разработки через 5 лет. Ретроспектива

    Жду дальнейшее разделение клиента и сервера, т е дальнейшее утончение клиента. Скриптовые клиенты будут развиваться. За 5 лет они никуда еще не денуться, но приблизяться к исчерпанию себя. Массоввыми станут «многоплатформенные» фреймворки типа Xamarin и пр, само собой полностью умрет нативное мобильное программирование. Ожидаю появления задатков технологий для объединения мобильных и браузерных приложений. Data Science однозначно шагнет еще дальше вперед, но тут я уже не очень силен. Но каких либо революций пока не ожидаю.
    А вот украинский рынок IT может сильно ужаться если мы не перейдет от упора на количество в сторону качества ибо сейчас мы сильно завязаны на успех бизнеса клиента и всего лишь делим с ним его прибыль если он успешен, но мы не предлагаем ему помощь в получении той самой прибыли и не учавствуем в его биззнесе. В этом большой риск и мы видели уже это в кризи 2008 когда масса укр IT-компаний выгоняла на улицу целые команды. Бланго тогда все улеглось за пару месяцев.
    ВСЕ ИМХО конечно.

  • Антипаттерналии I. О конструктивной и деструктивной лени

    Во всем должно быть рациональное зерно. Писать надо изначльно красиво, аккурано и гибко, чтоб потом изменения вностились с минимальной кровью. С другой стороны не всегда рефакторинг полезен — лично принимал участие в проектах, написанных мной же, но очень давно, где надо было просто поддерживать систему и ее развития в будущем не предвиделсь. Если рефакторинг и производился то локальный. У КАЖДОГО ПРОЕКТА ЕСТЬ СВОЕ ВРЕМЯ ЖИЗНИ! После этого он навсегда умирает и ему на смену приходит абсолютно новый, более новый, навороченный и изящный. С программистами таже беда, что и с всем извесным художником, которого не пускали на свою же собственную выставку с красками и кистью, что б он там часом ничего не подправил. Каждый менеджер должен чувствовать момент, после которого он должен сказать — «Стоп! На этом мы ставим точку.» Зачастую например более продвинутые и изящные решения для часто-повторяемой проблемы (патерн) лучьше не вносить в написанный и работающий проект, если старый патерн работает без нареканий. Это может вообще развалить проект, т к новое решение не оттестировано к томуже не вписывается в целостную архитектуру устаревшей системы, что внесет хаус. А вот старое работает годами, вписывается в архитектуру и есть куча народу которые знают как его использовать и чинить. поэтому доля консерватизма в принячтии решений по рефакторингу должна присутсвовать. Не забывайте в конце концов что за все это комуто придется платить...Так что