Adım 3: Somut Öneriler
Öncelik listesinin tepesindeki her iş akışı için belirli bir araç adlandırır ve nedenini açıklarız. "AI kullanın" değil. "İş akışı otomasyonunu düşünün" değil. Tek satır gerekçe ve gerçekçi bir efor tahmini ile belirli bir araç. Denetimin kendisini hak ettiği yer burasıdır.
Neye bakarız
Araçları dört şeye göre seçeriz: ekibinizin teknik konforu, mevcut yığınınız, hem inşa hem bakım için bütçeniz ve otomasyon bozulursa risk iştahınız. Aynı iş akışının farklı ekipler için farklı doğru cevapları olabilir. Bir şirkette n8n gerektiren bir iş akışı, başka bir şirkette Zapier zap'i gerektirebilir, çünkü bir şirketin JSON'da rahat bir geliştiricisi var, diğerinin yok.
En sık önerdiğimiz dört araç kategorisi: iş akışı orkestrasyon platformları (kendi sunucusunda n8n veya yönetilen istiyorsanız Zapier/Make); küçük bir özel kod parçası (zamanlanmış işteki bir Python betiği, bir sunucusuz fonksiyon); yerel bir satıcı entegrasyonu (satıcının zaten sunduğu entegrasyonu kullanın, biraz daha az esnek olsa bile); ve yapılandırılmamış girdi iş akışları için LLM tabanlı bir ajan. İş akışı özellikle talep etmedikçe daha ayrıntılı bir şey önermekten kaçınırız.
Her öneri için 'neden bu ve neden bariz alternatif değil' diye bir cümle yazarız. O cümle en önemli kısımdır. O olmadan bir öneri sadece bir marka anmasıdır.
Bu aşamada yaygın hatalar
Moda aracı önermek. LLM'ler güçlüdür, ama her zaman doğru araç değildirler. Girdi yapılandırılmışsa ve kural deterministikse, 30 satırlık bir betik daha ucuz, daha hızlı, daha güvenilir ve daha kolay hata ayıklanır. Girdi gerçekten yapılandırılmamışsa (e-postalar, serbest metin biletleri, belgeler) ve çıktı yumuşak yargıdan faydalanıyorsa LLM kullanırız. Aksi takdirde kullanmıyoruz.
Satıcı bir entegrasyon sunuyorken özel inşa önermek. CRM'iniz ve muhasebe aracınızın zaten yerel bir entegrasyonu varsa, onu kullanın. Özel entegrasyonlar, orijinal ROI matematiğinde neredeyse hiçbir zaman dürüstçe hesaba katılmayan devam eden bir bakım maliyetidir.
'Bir geliştiriciye ne sorulmalı' ayrıntısını atlamak. Bir öneri tek başınıza makul olarak yapamayacağınız teknik bir yargı gerektiriyorsa, bunu açıkça söyleriz ve devam etmeden önce bir geliştiriciye sormanız gereken belirli soruları dahil ederiz. Teslimatın bu kısmı bazen önerinin kendisinden daha faydalıdır.
Bu adım pratikte nasıl görünür
Her önerilen iş akışı kısa bir yazı alır — tipik olarak yarım sayfa — şunlarla: önerilen yaklaşım bir cümlede, değerlendirip reddettiğimiz alternatif (yine bir cümlede), tahmini inşa süresi aralığı, bir bakım beklentisi ve devam ederseniz bir geliştiriciye sormanız gereken belirli sorular. Bir aracın hacminiz için muhtemelen yeterli olan ücretsiz bir katmanı varsa söyleriz; yoksa gerçekçi aylık maliyeti adlandırırız.
Önerinin doğrulayamadığımız bir kısıtlamaya bağlı olduğu yerlerde (örn. 'bu, destek hacminizin ayda 5.000 biletin altında kalacağını varsayar'), kısıtlamayı açıkça adlandırırız. Amaç, varsayımı matematiğin içinde gizlemek değil, varsayımımız yanlışsa öneriye itiraz etmeyi kolaylaştırmaktır.