Задать вопрос
  • Как удалить нелегальную копию своего сайта?

    Думаю стоит начать с заявление в МВД
    Ответ написан
    Комментировать
  • Штатные программисты или аутсорсинг?

    @sisn
    Если объемы работ большие и регулярные и примерно более-менее квалификацию требуют - выгоднее свой.

    Если работы эпизодические - выгоден аутсорс.
    Если работы требуют огромных скачков по квалификации - выгоден чужой (своего высококвалифицированного кормить каждый день, даже когда можно было обойтись дешевым сотрудником - накладно весьма).
    Ответ написан
    Комментировать
  • Штатные программисты или аутсорсинг?

    @Andrey052
    Программист
    Если много работы, то штатный будет дешевле в десятки раз, чем приходящий и временами и пропадающий неделями не понятно кто. Если работы мало, то можно и на аутсерс отдать.
    Ответ написан
    Комментировать
  • Штатные программисты или аутсорсинг?

    chewarer
    @chewarer
    (c) Есть такая профессия - на работе сидеть.
    Ответ написан
    Комментировать
  • Штатные программисты или аутсорсинг?

    @azzzimo
    Если ваш бизнес по большей части - не_IT - то аутсорс конечно выгоднее. Как говорил Milfgard - возможность платить когда есть деньги и не платить, когда денег нет - очень важна для выживания бизнеса.

    Если эта поддержка сайтов и бухгалтерского ПО - основная работа компании - то отдавать на аутсорс плохая идея.
    Ответ написан
    Комментировать
  • Штатные программисты или аутсорсинг?

    @ahosta
    Если есть постоянные большие объемы работ - штатники.
    Если есть отдельные работы, повышенной сложности, что штатники не осилят - аутсорсеры, в дополнение к штатникам.
    Если есть постоянные резкие скачки объемов работ на небольшое время - аутсорсеры, в дополнение к штатникам.
    Если объемы работ невелики - аутсорсеры.

    Если объем работы на одного-единственного программиста - не рекомендую. Он завянет в одиночестве. Упадет и качество и скорость и проверить его будет некем. И если с ним чего случится - будет весьма проблематично за ним разобраться.
    Ответ написан
    Комментировать
  • Штатные программисты или аутсорсинг?

    По своему опыту работы как на аутсорсе так и в штате могу сказать следующее:
    аутсорсеры могут легко и внезапно свалить из проекта, часто не говоря ни слова
    могут откровенно халтурить (писать говнокод например), так как нет менеджеров/начальника стоящих за спиной
    могут работать ночью в полусонном состоянии, так как днем жена и дети мешают работать
    и много чего еще. Хорошего аутсорсера найти легко, но он будет стоить гораздо дороже.
    UPD: для остальных членов команды это означает следующее:
    - сплошной и вездесущий говнокод
    - отсутствие единого стиля программирования
    - долгое вникание в исходный код
    А в общем это называется бардак.
    Ответ написан
    1 комментарий
  • Штатные программисты или аутсорсинг?

    Sanes
    @Sanes
    Здесь не может быть однозначного ответа. Много условий.
    Ответ написан
    Комментировать
  • Штатные программисты или аутсорсинг?

    @evikbook
    DevOps
    У меня в компании есть опыт работы с штатными и оутсорсерами. Раздолбаи есть везде. Все зависит от человека и как построите рабочие процессы (постановка задачи, контроль временных ресурсов и тп). Поэтому первый мой совет "Посмотрите, что проще Вам будет контролировать: удаленного или штатного". Мы в итоге выбрали путь "штатный удаленный сотрудник". Так как продукты у нас сложные и иногда месяца мала, чтобы въехать во все процессы. Тут преимущества в том, что если Вы в Москве, то можно найти хорошего компетентного коллегу за умеренную зп. Плюс не требуется разжевывания задачи или детального тз, человек в теме и по названию тикета уже понимает 80% всех работ. Да, через 3-4 месяца с удаленным сотрудником мы стали общаться практический только через тикетную систему. Что с оутсорсерами выглядит мало вероятным (если они будут часто меняться) Так-же оутсорсер на Вас "жениться не обязан", то есть он и другими проектами может заниматься и быть в них погружен больше чем в Ваши проблемы.
    Ответ написан
    Комментировать
  • Штатные программисты или аутсорсинг?

    @VekaVeka
    1. Регулярность работы, объемы работ.
    Штатные дешевле если есть постоянные объемы работы.

    2. Квалификация и сложность работ.
    Аутсорсера легче нанять даже если у него высокая квалификация.
    Штатный высокой квалификации - это должна быть действительно огромная необходимость и сложные долговременные задачи с соответствующими бюджетами.

    В 1990 года - тогда да, все держали своих программистов и все пилили свой софт.
    В начале 2000 - содержали своих админов, и иногда программистов.

    Сейчас нормой является аутсорсинг.
    Стали умнее и стали считать деньги.

    Штатный программист ничего не гарантирует.

    Штатного программиста одного держать сложно - ему профессионально скучно.

    Если задачи позволяют/требуют держать 3 и более квалифицированных человек, тогда штатники уже выгодно.
    Иначе - вы их даже толком проконтролировать не сможете.
    Ответ написан
    Комментировать
  • Штатные программисты или аутсорсинг?

    @poiuy7
    Найти хороших "Оутсорсеров" очень сложно. Как правило это очень некачественная работа.
    (у них работа по принципу как-то сделать и получить побольше)
    И за их некачественную проделанную работу в будущем вы будете платить больше, что покроет все сэкономленные траты.

    Хорошие штатные программисты будут стоить дорого, но лучше иметь 5 хороших программистов чем 10 плохих.

    Если объём задач неравномерный (типа 1 месяц большая загразку, а 2 месяца делать особо нечего).
    То имеет смысл держать небольшое количество штатных программистов и привлекать "Оутсорсеров", но по принципу, что штатные программисты полностью контролирую работу оутсорсеров.
    Ответ написан
    7 комментариев
  • Штатные программисты или аутсорсинг?

    bingo347
    @bingo347
    Crazy on performance...
    Штатные программисты:
    + работают в долгосрочной перспективе (после разработки будет поддержка теми же людьми)
    + сидят у Вас в офисе (коммуникации в команде проще и больше)
    - им нужно платить фиксированую зп (как правило, например в СПб Вам это обойдется от 50 (джуниор) до 150 (сеньер) тыс в месяц на человека)
    - нужно предоставить рабочее место (стол, стул, комп и т.д.)
    - редко работают больше рабочего дня (хотя если будете доплачивать за переработки, то будут)

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

    Выбирайте
    Ответ написан
    11 комментариев
  • Как организовать коммуникацию с заказчиком?

    Andrey_Pletenev
    @Andrey_Pletenev
    Pletenev.com
    Внезапно стало неудобно и непродуктивно общаться с заказчиками, которых набралось под 50 и с ними нужно взаимодействовать и отслеживать состояние процесса разработки в актуальном состоянии одновременно.

    Способы коммуникации по степени убывания эффективности:
    • личное общение
    • видеосвязь (скайп и пр.)
    • телефон
    • переписка

    В вашем случае, в тикетах рекомендую фиксировать только итоги устных договоренностей.

    Как унифицировать отдельное хранение файлов и документов - кто то одним файлом ТЗ шлёт, кто то порознь и в разных форматах?

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

    Как организовать демонстрацию результатов и сбор фидбэков по ним?

    Предварительные демо поднимаете на своем сервере. Показываете сами или даете доступ. Фидбэк устный получаете в ходе показа (фиксируете письменно), фидбэк письменный от самостоятельного ознакомления просите прислать сразу в тикеты или почтой. Приемку проводите по плану приемки, который должен быть частью ТЗ. Финальный фидбэк - подписание актов.

    Как организовать совместное с заказчиком участие в процессе тестирования?

    Обычно заказчик соглашается на участие в тестировании в следующих случаях:
    a) заказчик внутренний, b) низкое доверие к вашему тестированию или c) заказчик хочет съэкономить и согласился тестирование взять на себя. В остальных случаях - тестирование - это ваша задача. Заказчик хочет получить демонстрацию и увидеть, что все прекрасно, а не ваши баги. Ну а если смотреть шире, то любое обнаружение бага в ходе эксплуатации, является тестированием силами заказчика. :)
    Ответ написан
    1 комментарий
  • Как организовать коммуникацию с заказчиком?

    @Pagliaccio
    Внедряю CRM
    Андрей, у вас получается пул разных задач и под них целесообразно использовать разные системы:
    Внезапно стало неудобно и непродуктивно общаться с заказчиками, которых набралось под 50 и с ними нужно взаимодействовать и отслеживать состояние процесса разработки в актуальном состоянии одновременно.

    Для управления коммуникациями с заказчиком - CRM-система (их множество, я работаю в bpm'online), в ней фиксировать все контактные данные, связи между клиентами и контактами, планировать встречи и звонки, желательно туда же завернуть электронную почту.

    Процесс разработки - система управления проектами, можно в самой CRM-системе вести список объектов их статус, сроки и % выполнения.

    Почта перестаёт работать, как инструмент коммуникации, после вложенных друг в друга 15 сообщений. Разбивка сообщений по темам и сообщениям объём переписки только увеличивает и запутывает.

    Обсуждение отдельных организационных тем всё равно придётся вести в почте - это самый эффективный на данный момент инструмент, позволяющий фиксировать историю и договорённости. Разбивать переписку по темам - хороший вариант, в конце договорённостей - резюме.
    Обсуждение проектных задач вынести в систему описания задач (можно пользоваться любой wiki-системой, начиная от платной Confluence, до MediaWiki и т.п. или использоваться связку NextCloud+LibreOffice Collaborate для командного онлайн-редактирования документов - я пользуюсь вторым набором).

    Как унифицировать отдельное хранение файлов и документов - кто то одним файлом ТЗ шлёт, кто то порознь и в разных форматах?

    Определить свой формат ТЗ и приводить все документы к единому виду и единой структуре. И своё хранилище с разграничением доступа (я, опять же, пользуюсь NextCloud)

    Как организовать демонстрацию результатов и сбор фидбэков по ним?

    Перед передачей результата работ в тестирование составить тест-кейсы, в которых с одной стороны должно быть описаны действия пользователя и плановый результат, а с другой стороны пользователь укажет что у него реально получилось и какие замечания. Для этого тоже есть свои системы, мне пока обычных текстово-табличных документов хватает - если делать ТЗ в виде пользовательских историй, то их же потом можно в качестве тест-кейсов использовать.

    Как организовать совместное с заказчиком участие в процессе тестирования?

    Этот процесс лучше разделять на три: внутреннее тестирование + обучение + тестирование заказчиком с заполнением тест-кейсов.

    Можно ещё почитать книгу М.Кон Пользовательские истории - неплохо описан процесс и порядок организации Agile-разработки.
    Ответ написан
    Комментировать
  • Как организовать коммуникацию с заказчиком?

    @kn0ckn0ck
    Продюсер
    Я думаю выходом будет работа в инструменте, который объединяет в себе совместную работу над ТЗ и планирование/контроль задач по исполнению этого ТЗ (макеты, доработки и т.п.).

    Заводите под заказчика отдельный проект, в нем есть Wiki, в ней можно писать требования или можно импортировать из MSWord, в чем там заказчик ТЗ изначально записывает. Там же можно обсуждать разделы ТЗ, добавлять макеты, их обсуждать и т.п. Заказчика запускаете в проект.

    По каждому разделу ТЗ создаете задачи на подготовку макетов, доработку ТЗ, реализацию (разработку). Там же видите их статус (выполнено/не выполнено).

    Все это можно организовать при помощи связки онлайн-редакторов (google docs, dropbox paper) и таск-менеджеров. Но, имхо лучше в одном сервисе это иметь, например, как сделано в scrumboard. В базе знаний пишем требования, на основе статей базы знаний создаем доработки или задачи - что еще нужно?
    Ответ написан
    Комментировать
  • Как правильно организовать раздел на Joomle?

    xmoonlight
    @xmoonlight
    https://sitecoder.blogspot.com
    Есть туча расширений.
    Например, FILEman.
    Посмотрите все от joomlatools (думаю, что многое должно подойти под эту задачу): https://www.joomlatools.com/extensions/
    Ответ написан
    2 комментария
  • Как активировать опцию демонстрации экрана в Skype?

    Никак, скайп для линукс это веб-версия в обертке, в веб версии нет демонстрации экрана.
    Ответ написан
    Комментировать
  • Как найти фрагмент кода в Битрикс?

    gromdron
    @gromdron
    Работаю с Bitrix24
    Универсальный алгоритм поиска:

    1) Открываем urlrewrite.php, смотрим есть ли правило для данной страницы. Если есть - открываем страницу из правила, если нет - ищем физическую страницу
    2) Смотрим наличие кода компонентов на данной странице, проверяем включаемые области. Если проект тестовый, то можно по одному убирать компоненты, пока не найдете.
    Если убрали все компоненты, а надпись выводится, то идем дальше
    3) Открываем настройки сайта и смотрим какой шаблон выводится на данной странице. Открываем его по ssh (как header.php так и footer.php) смотрим компоненты, включаемые области, области с отложенными функциями (ShowViewContent)
    4) Если надпись все еще не выводится, смотрим события страницы

    Делая все 3 шага Вы сможете найти что угодно в Битриксе.
    Как пример, данная область может быть:
    1) Физическим тестом на странице
    2) Включаемой обастью подключаемой на странице
    3) Результатом работы компонента
    4) Отложенным результатом компонента
    5) Физическим текстом в шаблоне
    6) Результатом работы компонента в шаблоне
    7) Результатом работы отложенной функции в footer.php
    8) Результатом работы отложенной функции на событиях страницы
    Ответ написан
    2 комментария
  • Ссылочный тип данных JavaScript?

    mr_T
    @mr_T
    Web-разработчик
    В первом случае ты передаешь в newArr указатель на массив, потом изменяешь этот же массив через указатель arr.
    Во втором случае ты снова передаешь указатель в переменную newArr, а потом просто присваиваешь переменной arr другое значение, то есть убираешь из нее указатель, но не затираешь само значение. Мало того - ты вручную вообще никак не затрешь значение любого объекта, ты можешь только "забыть" о нем, а уберет его за тебя уже либо сборщик мусора, либо просто вся выделенная память затрется при перезагрузке страницы.
    Ответ написан
    Комментировать
  • В чем смысл Vanilla.js?

    @Vovchikvoin
    Забей, это тупая шутка, я таких называю дрочеры, куча понтов, давайте все на нативном ага удачи, проект чуть больше магазина, попробуй напиши на чистом js.
    Ответ написан
    8 комментариев